[llvm-dev] [RFC] "Properly" Derive Function/Argument/Parameter Attributes

[Hal Finkel via llvm-dev]

Hi, Johannes,

I'm certainly in favor of rewriting the attribute deduction so that it's
more consistent and more powerful. There's a lot more that we could do.
I'll help to review the patches.

On 08/23/2018 10:25 AM, Johannes Doerfert via llvm-dev wrote:
> After I spend some time working with the function attribute* deduction
> pass** [1,3], I would like to propose a "proper" organization***.
>
>
>
> Why?
>
>   Because we do not derive nearly as many attributes as we could****,
>   while we do maintain various (separate and diffently organized)
>   "data-flow-like analyses" to do so.
>
>
>
> What else?
>
>   I propose a single optimistic data-flow (fixpoint) loop to perform the
>   deduction (similar to [2,3] but for all propagation forms and not only
>   call sites -> callee).

Right now, as I recall, we apply an optimistic fixed-point optimization
to each SCC, moving up the call graph from leaves to root. When you say
that you want a more-general inference, besides just call sites ->
callees (and the existing callees -> callers), can you please elaborate?
Doing both of these at the same time as part of a optimistic fixed-point
optimization seems to imply that the iteration will involve the entire
call graph at once (or, at least, each connected component at once). Is
that what you have in mind?

>  Given that a pessimistic initialization allows
>   to terminate early, we can then also vary the compile time investment.

This is certainly a true statement, but I don't understand what you're
proposing. Are you saying that we should have both an optimistic and
pessimistic mode?

Thanks again,
Hal

>
>
>
> Where is the catch?
>
>   It will require a substantial rewrite with (some) parts that cannot be
>   split in small independent patches. While I believe these to be easy
>   to review*****, I want to know if
>     (1) there is interest in having better attribute deduction, and
>     (2) there are volunteers to review such patches.
>
>
>
> I do appreciate any input on this proposal.
>
> Cheers,
>   Johannes
>
> --------
>
> * It derives function attributes but also parameter and argument
>   attributes.
>
> ** lib/Transforms/IPO/FunctionAttrs.cpp
>
> *** This statement is intended to sound harsh. I believe it to be
>     appropriate because it is hard to find consistency in the current
>     implementation. Different parts perform argument deduction similarly
>     but still different. This does lead to code duplication and missed
>     deductions as there is no information exchange going on.
>
> ****  This includes missing attributes in existing propagations
>       e.g., dereferencability (see also [0,1]), missing forms of
>       propagation, e.g., call sites -> callee (see [2,3]), as well as
>       missing deductions due to the fact that there is no (global)
>       fixpoint iteration. Additional examples to showcase some current
>       shortcomings are attached to this mail.
>
> ***** In the sense that they will "just contain" the implementation of a
>       fixpoint data-flow analysis. The logic to determine/eliminate
>       attributes will be similar to the one we have now.
>
>
> [0] https://reviews.llvm.org/D48387
> [1] https://reviews.llvm.org/D50107
> [2] https://reviews.llvm.org/D4609
> [3] https://reviews.llvm.org/D50125
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

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