[llvm-dev] Missing attribute inference cases

Philip Reames via llvm-dev llvm-dev at lists.llvm.org
Fri Feb 16 10:48:10 PST 2018

On 02/16/2018 10:29 AM, Philip Reames via llvm-dev wrote:
> This email is just to summarize a bit of digging I did last night into 
> our attribute inference.  Unfortunately, I'm not going to have time to 
> implement any of the gaps I noticed, but I figured someone else out 
> there might be interested.
> *Missing Attributes*
> argmemonly - influences AA, particularly relevant for libraries which 
> wrap build in functions which are annotated, but don't manually 
> annotate the wrappers
> dereferenceable - influences speculation safety, this primarily drives 
> LICM, but can also effect things like PRE -- probably best to 
> implement as a deref_or_nuill analysis and then merge nonnull 
> inference to promote
> dereferenceable_or_null - see previous
> nounwind - currently implemented in PruneEH, missing in new pass 
> manager -- this one will get fixed in the near future
Other cases I just noticed...
noreturn -- useful for exception throw wrappers
allocsize -- useful for allocation wrappers
writeonly -- useful for AA
speculatable - useful for speculation, LICM, PRE, etc...

> *Untrusted Declarations*
> In several cases, we check hasExactDefinition before checking 
> properties of the function declaration (such as return type). To my 
> knowledge, facts on declarations are valid even in the place of 
> derefinement.  This results in the analysis being unnecessarily 
> conservative around external declarations.
> *AlwaysInline and hasExactDefinition*
> I believe, but have not fully thought through, that it is legal to IPO 
> across an inexact definition boundary if a particularly callsite or 
> declaration is marked alwaysinline.  It's not clear this matters since 
> we'll eventually inline it anyway, but this might be a compile time 
> savings by simplifying callers earlier than otherwise possible.
> Philip
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180216/35789bac/attachment.html>

More information about the llvm-dev mailing list