[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