[llvm-dev] [cfe-dev] RFC: Supported Optimizations attribute

[Philip Reames via llvm-dev]

On 12/5/18 12:57 AM, Piotr Padlewski wrote:
>
>
> śr., 5 gru 2018 o 00:22 John McCall via cfe-dev 
> <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> napisał(a):
>
>     On 4 Dec 2018, at 17:50, Philip Reames wrote:
>
>         Skimming along, apologies if I'm repeating something which
>         already got said.
>
>         If I understand this correctly, the basic problem we're trying
>         to solve is to use a local hint (the invariant.group) to make
>         a global assumption about other code which might exist
>         elsewhere outside the function.  The attribute proposed can
>         basically be phrased as describing a universe of functions
>         within which our desired global property holds. There's an
>         ambiguity about what is allowed to be assumed about code
>         outside that universe.
>
>         I think it's important to note that we have a precedent of
>         something similar to this in TBAA. TBAA information coming
>         from different modules has the same base problem.  We solve it
>         by using the "root" of the TBAA tree as a scope descriptor,
>         and essentially making two TBAA nodes from distinct roots
>         incomparable.
>
>         Can someone explain concisely why a similar scheme couldn't be
>         used to solve this problem?
>
>     TBAA is conservative in /two/ ways:
>     - It allows two accesses to alias if they have TBAA nodes with
>     different roots.
>     - It allows two accesses to alias if only one of them has a TBAA node.
>
>     The second is what doesn't generalize: there are optimizations
>     where you need to
>     rely on transition points being explicitly identified. Looking at
>     a function
>     with no identified transition points, you don't know whether it
>     actually doesn't
>     transition or whether it was compiled without the transitions
>     being explicitly
>     marked. There's no way to extend the TBAA idea to make that work.
>
> The other reason why similar scheme doesn't work for !invariant.group 
> is that we rely on a calls to launder/strip being present for some 
> constructs to preserve
> information about invartianess of an object (like in the example from 
> RFC).

I'm really not sure I buy this.  You're effectively saying that you have 
two points which need to share a common root: 1) the "transition point" 
and 2) the invariant.group marker.  If it were possible to mark the 
transition point with a metadata node - is it? - the exact same rules as 
used for TBAA work just fine.

p.s. It would help me a lot if you'd spell out specific examples of 
transition points.  I checked the RFC and don't see them.


>         On 12/4/18 11:24 AM, John McCall via llvm-dev wrote:
>
>             Note that IPO is generally permitted to partially inline
>             or outline code,
>             and so good-faith optimizations that e.g. require two
>             instructions to be moved
>             in tandem or not at all must use tokens to establish that
>             unbreakable
>             relationship.
>
>         I think the way your framing this is dangerous.  We absolutely
>         can not allow any annotation of this form to *weaken* the
>         semantics of the existing IR.  We can and should impose a
>         criteria that any extension of this variety strictly add
>         information to the IR which might not have been previously
>         inferred.  We can then design rules for how to preserve our
>         new information as long as possible, but framing this in terms
>         of disallowed transformations is really a non-starter.
>
>     That's exactly what I was trying to convey here. Authors of good-faith
>     optimizations need to design their representations so that
>     transformations
>     that know nothing about their optimizations but merely preserve
>     semantics
>     and well-formed IR structure will not break their representations.
>     The only
>     transforms that need to know about the existence of good-faith
>     optimizations
>     are interprocedural optimizations; furthermore, those
>     optimizations don't
>     need to know about any good-faith optimizations specifically, they
>     just need
>     to understand how to correctly update the supported_optimizations
>     list.
>     That is a very small burden on IPO that enables an interesting
>     class of
>     language-specific optimizations.
>
>     John.
>
>     _______________________________________________
>     cfe-dev mailing list
>     cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
>     http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181205/f3b27ef2/attachment.html>