[llvm-dev] Missing attribute inference cases

[Davide Italiano via llvm-dev]

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



-- 
Davide

"There are no solved problems; there are only problems that are more
or less solved" -- Henri Poincare