search for: getfnattribut

...llvm-lto`, `llvm-link`, `libLTO.dylib`), defaults should be pushed down as explicit function attributes. Default function-level attributes ================================= I've attached patches with a reference implementation. - 0001: Canonicalize access to function attributes to use `getFnAttribute()` and `hasFnAttribute()`. (This seems like a nice cleanup regardless?) - 0002: Add the feature. - 0003: Use it in `clang` for function attributes based solely on `CodeGenOptions`. They look like this in assembly: attributes default = { "no-frame-pointer-elim"="fa...

...defaults should be pushed down as explicit function attributes. > > Default function-level attributes > ================================= > > I've attached patches with a reference implementation. > > - 0001: Canonicalize access to function attributes to use > `getFnAttribute()` and `hasFnAttribute()`. (This seems like a nice > cleanup regardless?) > - 0002: Add the feature. > - 0003: Use it in `clang` for function attributes based solely on > `CodeGenOptions`. > > They look like this in assembly: > > attributes default = { &q...

...tes. >>> >>> Default function-level attributes >>> ================================= >>> >>> I've attached patches with a reference implementation. >>> >>> - 0001: Canonicalize access to function attributes to use >>> `getFnAttribute()` and `hasFnAttribute()`. (This seems like a nice >>> cleanup regardless?) >>> - 0002: Add the feature. >>> - 0003: Use it in `clang` for function attributes based solely on >>> `CodeGenOptions`. >>> >>> They look like this in assembly:...

...for (Module::iterator functionIter = module->begin(); functionIter != module->end(); functionIter++) { if (functionIter->isDeclaration()) continue; Attributes attributes = functionIter->getFnAttributes(); if (!attributes.hasAttribute(Attributes::AlwaysInline)) { functionIter->addFnAttr(llvm::Attributes::AlwaysInline); errs() << "AlwaysInline NOT detected\n"; modified = true;...

Hi Arnaldo, On 05/11/12 10:02, Arnaldo wrote: > Hi Duncan, thanks for the quick answer. > > Yes I'm sure the runOnModule is being called, and when I dump the functions > before exiting the method I can see the AlwaysInline attribute. > > I'll check InlineAlways.cpp and will reimplement as last resource but I still > wonder why this is not working. if you want more

Hi Duncan, thanks for the quick answer. Yes I'm sure the runOnModule is being called, and when I dump the functions before exiting the method I can see the AlwaysInline attribute. I'll check InlineAlways.cpp and will reimplement as last resource but I still wonder why this is not working. On Mon, Nov 5, 2012 at 5:03 PM, Duncan Sands <baldrick at free.fr> wrote: > Hi Arnaldo,

...use because they do too much information hiding. In particular, the choice to make AttributeSetNode an internal implementation detail of lib/IR is problematic. This type describes all of the attributes on an individual argument, return value, or function, which IPO transforms often want. Today the getFnAttributes, getRetAttributes, and getParamAttributes APIs find the relevant AttributeSetNode* and wrap it in a new, uniqued AttributeListImpl. This requires callers to keep around the index of the extracted attributes so they can look through the wrapper list. If we make AttributeSetNode public, we can simp...

Hi Sanjay, Thanks, I saw this flag and it's definitely should be considered, but it appeared to me to be static characteristic of target platform. I'm not sure how appropriate it would be to change its value from a front-end. It says "Has", while optional flag would rather say "Uses" meaning that implementation cares about floating point exceptions. Regards, Sergey

...es().hasAttribute(AttributeSet::FunctionIndex, Attribute::MinSize); + // Target cares about IEEE754 conformant FP exceptions at run-time? + HonorFPExceptions = F.hasFnAttribute("honor-fp-exceptions") && + (F.getFnAttribute("honor-fp-exceptions") + .getValueAsString() == "true"); + /// Builder - This is an IRBuilder that automatically inserts new /// instructions into the worklist when they are created. IRBuilder<true, TargetFolder, InstCombineIRInserter> diff...

Hello , To solve this bug locally I have given preference to tail call optimization over local function related optimization in IPRA. I have added following method to achieve this: bool isEligibleForTailCallOptimization(Function *F) { CallingConv::ID CC = F->getCallingConv(); if (CC == CallingConv::Fast || CC == CallingConv::GHC || CC == CallingConv::HiPE) return true; return false;

According to this http://llvm.org/docs/CodeGenerator.html#tail-call-section, it seems that adding a new CC for the purpose of local function optimization seems a good idea because tail call optimization only takes place when both caller and callee have fastcc or GHC or HiPE calling convention. -Vivek On Sun, Jun 26, 2016 at 1:26 AM, vivek pandya <vivekvpandya at gmail.com> wrote: >