[llvm-dev] RFC: Supported Optimizations attribute (original) (raw)

Philip Reames via llvm-dev llvm-dev at lists.llvm.org
Tue Dec 4 14:50:21 PST 2018

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 at apple.com <mailto:jmccall at apple.com> wrote: Piotr's proposal unfortunately doesn't give us a good name for the class of optimizations that require being listed in supportedoptimizations. 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 supportedoptimizations 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 supportedoptimizations as mentioned in Piotr's proposal --- and, in particular, will intersect the supportedoptimizations 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 supportedoptimizations 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 supportedoptimizations? Good question. I would consider that to be an unacceptable intrusion: intraprocedural transforms should never have to be aware of supportedoptimizations (unless they're implementing a good-faith optimization, of course) and interprocedural transforms should only have to be aware of supportedoptimizations 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 supportedoptimizations --- will never introduce new UB. John.

LLVM Developers mailing list llvm-dev at lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181204/9d9fb51c/attachment.html>

More information about the llvm-dev mailing list