(original) (raw)

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?

On 12/4/18 11:24 AM, John McCall via llvm-dev wrote:

On 4 Dec 2018, at 13:16, Sanjoy Das wrote:

On Mon, Dec 3, 2018 at 11:49 PM John McCall jmccall@apple.com wrote:

Piotr's proposal unfortunately doesn't give us a good name for the class
of optimizations that require being listed in supported\_optimizations.
In earlier discussions I called them "brittle", but I can understand why
nobody wants to call their optimization that, so let's call them
"good-faith optimizations" instead since they rely on the good faith of
all the participating code.

Every optimization has to know how to maintain the structural rules of
LLVM IR; that's what makes them structural rules. We don't want the set of
structural rules to substantially change because such-and-such good-faith
optimization is in effect because that would require arbitrary transforms
to check the supported\_optimizations list before they knew which rules to
follow. Instead, the burden is on the optimization designer to pick IR
constructs that won't be messed up by an arbitrary transform with no special
knowledge of the optimization. The only thing the optimization designer
can rely on is this:

other transforms will preserve the apparent semantics of the function and
other transforms will maintain the standard structural rules of LLVM IR.

Ok. Just to make sure we're on the same page, if this was all there
is we would not need this attribute right? All LLVM optimizations do
need to preserve semantics and structural properties anyway?

We need this attribute because interprocedural optimizations otherwise
break good-faith optimizations, so yes, my suummary here is missing some
qualification (that I included in the next paragraph, but with a slightly
different spin). So let me restate this.

The designer of a good-faith optimization can rely on this:

other transforms will preserve the apparent semantics of the function,

other transforms will maintain the standard structural rules of LLVM IR, and

interprocedural transforms will honor supported\_optimizations as mentioned in Piotr's proposal --- and, in particular, will intersect the supported\_optimizations list whenever moving code into a function.

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.

So the defining property of a good-faith optimization is that:
\- there are rules which participating functions are expected to follow on
pain of undefined behavior but which LLVM IR doesn't require every function
to follow, and
\- those rules will be preserved by any transform that doesn't move code
between functions and which preserves the apparent function semantics
and maintains the standard structural rules of LLVM IR.

In other words, certain things are UB in functions tagged with
supported\_optimizations that are not UB otherwise? This breaks code
hoisting transformations right? I.e.
isSafeToSpeculativelyExecute(Inst) will have to return false if Inst
is in a function with a non-empty supported\_optimizations?

Good question. I would consider that to be an unacceptable intrusion:
intraprocedural transforms should never have to be aware of
supported\_optimizations (unless they're implementing a good-faith
optimization, of course) and interprocedural transforms should only have
to be aware of supported\_optimizations in the narrow sense outlined
by Piotr. If something about the optimization's representation in IR
is unsafe to speculate, it should be made impossible to speculate for
standard semantic/structural reasons, like having apparently arbitrary
side-effects.

I think the right way to formalize this is to say that, while the
good-faith optimization may impose additional UB rules on the function,
it must guarantee that transforms that are well-behaved as described
above --- i.e. that preserve standard structure and semantics and which,
if interprocedural, appropriately honor supported\_optimizations --- will
never introduce new UB.

John.
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
LLVM Developers mailing list  
llvm-dev@lists.llvm.org  
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev  