[llvm-dev] Missing attribute inference cases

[Philip Reames via llvm-dev]

SGTM

On 02/17/2018 03:52 PM, Nuno Lopes wrote:
> I can step in, if that's ok with you.
> Nuno
>
> -----Original Message----- From: Philip Reames
> Sent: Saturday, February 17, 2018 1:04 AM
> To: Davide Italiano ; Nuno Lopes
> Cc: llvm-dev
> Subject: Re: [llvm-dev] Missing attribute inference cases
>
> Sure, but is anyone willing to mentor?  I don't have time.  I can
> advise, but only infrequently.
>
> Philip
>
>
> On 02/16/2018 03:47 PM, Davide Italiano wrote:
>> Yes, I agree with you this sounds like a great GSoC.
>>
>> On Fri, Feb 16, 2018 at 3:42 PM, Nuno Lopes via llvm-dev
>> <llvm-dev at lists.llvm.org> wrote:
>>> 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
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev 
>