[llvm-dev] Missing attribute inference cases

[Nuno Lopes via llvm-dev]

Maybe we could list some of these as a GSoC project?
Seems like a self-contained task that can be simple as desired and as hard 
as the student wants it to be.

Nuno

-----Original Message----- 
From: Philip Reames via llvm-dev
Sent: Friday, February 16, 2018 6:48 PM
To: llvm-dev
Subject: Re: [llvm-dev] Missing attribute inference cases


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