llvm dev - Feb 2018 - Missing attribute inference cases

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

*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

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180216/b30ca871/attachment.html>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180216/35789bac/attachment.html>

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

Thanks for the digging!

A quick note:

On Fri, Feb 16, 2018 at 10:30 AM Philip Reames via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> *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.
>
We need to be careful here. Totally agree with you, just worried about
something somewhere *inferring* things onto declarations when it shouldn't
and a general lack of adequate understanding of the line between the good
and bad cases...

> *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.
>
Given pass ordering, I'd not worry about this. The inliner runs first (in
the new PM) and then we deduce attributes so we should already have nuked
any always_inline edges.

We also have the pre-call-graph cleanup passes that do most of the code
deletion and such prior to inlining.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180217/18472211/attachment.html>