[llvm-dev] Missing attribute inference cases

[Philip Reames via llvm-dev]

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
>
>