search for: hasfnattribute

...tributes()` only reflects the explicitly specified > > attributes, skipping those set as module defaults. > > > > Ick. Pretty severe limitation? I.e. how would it work to test general > attributes on a function during code gen? > > As long as everyone calls `Function::hasFnAttribute()`, there's no > problem. This proposal basically turns it into a bug to access > them directly; you need to go through `Function::hasFnAttribute()` > to get the right answer. (Not sure if there's a better way?) > > > > > - If an enum attribute is set as a defaul...

...d I build with -fno-builtin-puts. If I understand correctly, *foo* will be marked with "nobuiltin", but this code in simplifylibcalls looks at the printf: > > Value *LibCallSimplifier::optimizeCall(CallInst *CI) { > + Function *F = CI->getCalledFunction(); > + if (F->hasFnAttribute(Attribute::NoBuiltin)) return 0; > return Impl->optimizeCall(CI); > } > > In the context of LTO, it makes sense for the attribute to be on function bodies, not on prototypes. > Yeah, I noticed that after sending this patch. I modified it to check the function CI is in for that...

Hi Duncan, Been thinking about this a bit and a few comments/questions. I may have misunderstood some things in your mail though so please feel free to explain at me :) > Changing `clang` to store target defaults on the module will allow us to > continue to override them when running `llc`. The right precedence > would be: > > 1. Explicit attributes set on the function. >

...s the explicitly specified >> > attributes, skipping those set as module defaults. >> > >> > Ick. Pretty severe limitation? I.e. how would it work to test general >> attributes on a function during code gen? >> >> As long as everyone calls `Function::hasFnAttribute()`, there's no >> problem. This proposal basically turns it into a bug to access >> them directly; you need to go through `Function::hasFnAttribute()` >> to get the right answer. (Not sure if there's a better way?) >> >> > >> > - If an enum attr...

...at are the minimal things required to define such a CC? Other alternative that I have thought was to add new attribute for function and use it like following in TargetFrameLowering::determineCalleeSaves() // In Naked functions we aren't going to save any registers. if (MF.getFunction()->hasFnAttribute(Attribute::Naked)) return; Any suggestions / thoughts are welcomed ! Sincerely, Vivek -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160620/523dc115/attachment.html>

...llo\n"); } and I build with -fno-builtin-puts. If I understand correctly, *foo* will be marked with "nobuiltin", but this code in simplifylibcalls looks at the printf: Value *LibCallSimplifier::optimizeCall(CallInst *CI) { + Function *F = CI->getCalledFunction(); + if (F->hasFnAttribute(Attribute::NoBuiltin)) return 0; return Impl->optimizeCall(CI); } In the context of LTO, it makes sense for the attribute to be on function bodies, not on prototypes. -Chris

...`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"="false" } Limitations...

Thanks David, I have tried ‘MF.getFunction()->hasFnAttribute(Attribute::???)’, but it seems that the front-end ‘NoInstrumentFunction’ attribute is not propagated to the collection of LLVM IR attributes (no equivalent is in the ‘Attribute::AttrKind’ enum). It is not obvious that there is another mechanism, and I suspect that there is not due to the separatio...

...393846>: - Define AvailableAttrs and AvailableFunctionAttrs with type std::bitset<AttributeEndAttrKinds> instead of uint64_t - Update AttributeSetNode::hasAttribute() to use the std::bitset test function on AvailableAttrs to check if an enum attribute is present - Update AttributeListImpl::hasFnAttribute() to use the std::bitset test function on AvailableFunctionAttrs to check if an enum attribute is present llvm/lib/IR/Attributes.cpp<https://sdocc.itg.ti.com/ui#file:review=11893/version=393848>: - Update AttributeSetNode::AttributeSetNode() constructor to use the std::bitset's set funct...

...fno-builtin-puts. If I understand correctly, *foo* will be marked with "nobuiltin", but this code in simplifylibcalls looks at the printf: >> >> Value *LibCallSimplifier::optimizeCall(CallInst *CI) { >> + Function *F = CI->getCalledFunction(); >> + if (F->hasFnAttribute(Attribute::NoBuiltin)) return 0; >> return Impl->optimizeCall(CI); >> } >> >> In the context of LTO, it makes sense for the attribute to be on function bodies, not on prototypes. >> > Yeah, I noticed that after sending this patch. I modified it to check the fu...

Hi LLVMites! This patch adds the 'nobuiltin' attribute to to LLVM. This is needed during LTO, which right now ignores this attribute and command line flag. I want to make this an IR-level attribute instead of a target-dependent attribute because it's used during IR modification and not code generation. -bw -------------- next part -------------- A non-text attachment was scrubbed...

...This optimization results in confusing MemorySanitizer reports. >>>> Use of >>>> + // uninitialized value in this branch instruction is reported with >>>> the >>>> + // predecessor's debug location. >>>> + if (BB->getParent()->hasFnAttribute(Attribute::SanitizeMemory) && >>>> + BI->isConditional()) >>>> + return false; >>>> + >>>> Instruction *Cond = 0; >>>> if (BI->isConditional()) >>>> Cond = dyn_cast<Instruction>(BI->get...

...hed 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-eli...

...nly reflects the explicitly specified >>> attributes, skipping those set as module defaults. >>> >>> Ick. Pretty severe limitation? I.e. how would it work to test general attributes on a function during code gen? >> >> As long as everyone calls `Function::hasFnAttribute()`, there's no >> problem. This proposal basically turns it into a bug to access >> them directly; you need to go through `Function::hasFnAttribute()` >> to get the right answer. (Not sure if there's a better way?) >> >>> >>> - If an enum attri...

...sults in confusing MemorySanitizer reports. >>>>> Use of >>>>> + // uninitialized value in this branch instruction is reported with >>>>> the >>>>> + // predecessor's debug location. >>>>> + if (BB->getParent()->hasFnAttribute(Attribute::SanitizeMemory) && >>>>> + BI->isConditional()) >>>>> + return false; >>>>> + >>>>> Instruction *Cond = 0; >>>>> if (BI->isConditional()) >>>>> Cond = dyn_cast<In...

...>> 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: >>> >>&g...

...d to define such a CC? > > Other alternative that I have thought was to add new attribute for > function and use it like following in > TargetFrameLowering::determineCalleeSaves() > > // In Naked functions we aren't going to save any registers. > if (MF.getFunction()->hasFnAttribute(Attribute::Naked)) > return; > > Any suggestions / thoughts are welcomed ! > > Sincerely, > Vivek > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev...

...emorySanitizer reports. >>>>>> Use of >>>>>> + // uninitialized value in this branch instruction is reported with >>>>>> the >>>>>> + // predecessor's debug location. >>>>>> + if (BB->getParent()->hasFnAttribute(Attribute::SanitizeMemory) && >>>>>> + BI->isConditional()) >>>>>> + return false; >>>>>> + >>>>>> Instruction *Cond = 0; >>>>>> if (BI->isConditional()) >>>>>>...

...Add function attributes to this function. + /// + void addFnAttr(StringRef Kind) { + setAttributes( + AttributeSets.addAttribute(getContext(), + AttributeSet::FunctionIndex, Kind)); + } + /// \brief Return true if the function has the attribute. bool hasFnAttribute(Attribute::AttrKind Kind) const { return AttributeSets.hasAttribute(AttributeSet::FunctionIndex, Kind); Index: include/llvm/IR/Attributes.h =================================================================== --- include/llvm/IR/Attributes.h (revision 176874) +++ include/llvm/IR/Attributes.h (w...

Is there a way to find the IR that corresponds to a callee DAG node? In other words to get the function definition, attributes, etc.? Tia. Reed