search for: getfnattributes

As we encode more CodeGen and target-specific options in bitcode to support LTO, we risk crippling `llc` as a debugging tool. In particular, `llc` command-line options are generally ignored when a function has an attribute set explicitly, but the plan of record is for `clang` to explicitly encode all (or most) CodeGen options -- even the target defaults. Changing `clang` to store target defaults

+grosbach > On 2015-Feb-12, at 14:45, Reid Kleckner <rnk at google.com> wrote: > > Are llc command line options all that critical? It's not that hard to edit the attributes directly or remove them with sed. Maybe Jim can speak to this one better than I can, but the workflow I've heard concerns about is: - Got a codegen bug (PR or whatever). - Want to fiddle with

Hi Duncan The first patch is general goodness and I think should be committed now. The other 2 LGTM. Unless anyone fundamentally objects to module attributes, or has feedback on the patches themselves, then please commit. I didn’t see any problems with them. Thanks, Pete > On Feb 12, 2015, at 4:02 PM, Jim Grosbach <grosbach at apple.com> wrote: > > >> On Feb 12, 2015,

...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 simpli...

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

Hi again, It's partially done. My concern is that it won't be accepted as is because of adding the flag parameter in a lot of places. I'd like to show what it looks like (here, not on llvm-commit yet), maybe someone could suggest a better way. There are two sources of the flag: field of TargetOptions and function attribute. I had to add the later one for InstCombine pass. Still

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: >