[llvm-dev] Missing attribute inference cases
Nuno Lopes via llvm-dev
llvm-dev at lists.llvm.org
Sat Feb 17 15:52:28 PST 2018
I can step in, if that's ok with you.
From: Philip Reames
Sent: Saturday, February 17, 2018 1:04 AM
To: Davide Italiano ; Nuno Lopes
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.
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
>> as the student wants it to be.
>> -----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
>> attribute inference. Unfortunately, I'm not going to have time to
>> any of the gaps I noticed, but I figured someone else out there might be
>> Missing Attributes
>> argmemonly - influences AA, particularly relevant for libraries which
>> build in functions which are annotated, but don't manually annotate the
>> dereferenceable - influences speculation safety, this primarily drives
>> 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
>> the function declaration (such as return type). To my knowledge, facts
>> declarations are valid even in the place of derefinement. This results
>> the analysis being unnecessarily conservative around external
>> 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
>> eventually inline it anyway, but this might be a compile time savings by
>> simplifying callers earlier than otherwise possible.
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
More information about the llvm-dev