[cfe-dev] [llvm-dev] RFC: Supported Optimizations attribute
Philip Reames via cfe-dev
cfe-dev at lists.llvm.org
Wed Dec 5 09:10:18 PST 2018
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/cfe-dev/attachments/20181205/f3b27ef2/attachment.html>
More information about the cfe-dev
mailing list