[llvm-dev] RFC: Supported Optimizations attribute

[John McCall via llvm-dev]

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.

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