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

Arthur O'Dwyer via llvm-dev llvm-dev at lists.llvm.org
Tue Dec 4 12:05:04 PST 2018

On Tue, Dec 4, 2018 at 2:24 PM John McCall via cfe-dev < cfe-dev at lists.llvm.org> 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 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. [...] 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. Peanut gallery says: I don't fully understand the use-case or the domain, but this description sounds unworkable to me.

AIUI, there are two players here: the "brittle optimization" (which relies on some invariant), and the "transform" (which has the power to break that invariant).

The only two mathematically workable scenarios are: (A) The brittle optimization's invariant is "impossible to [break] for standard semantic/structural reasons." Therefore no transform ever needs to know anything about it. The result is a "robust" optimization, and no need for the supported-optimizations flagset. (B) The brittle optimization's invariant is, in fact, brittle. Any transform that doesn't explicitly preserve the invariant can and will break the invariant. Therefore, every transform must have its own whitelist of "invariants I know I don't break." Any flag in the supported-optimizations flagset which is not whitelisted by a given transform must be cleared when that transform is applied to the code. (Because, by definition, a transform that doesn't explicitly preserve the brittle invariant must be assumed to break it.)

my $.02, –Arthur -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181204/5ec18259/attachment.html>

More information about the llvm-dev mailing list