[llvm-dev] [cfe-dev] RFC: Supported Optimizations attribute

[John McCall via llvm-dev]

On 4 Dec 2018, at 11:16, Finkel, Hal J. wrote:
> On 12/4/18 1:49 AM, John McCall via cfe-dev wrote:
>
> On 4 Dec 2018, at 1:45, Sanjoy Das wrote:
>
> I think we should have some bounds on how "badly" a
> supported_optimizations tag on a function can affect its semantics.
> For instance, can a "supported_optimizations" invariant be that "the
> CFG is always structured"? Or (exaggerating to illustrate the point)
> "the function has an equal number of loads and stores"?
>
> 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.
>
> For example, if you need arbitrary side-effects to not be re-ordered 
> past
> some point in the function, you should put an instruction there that
> inhibits that kind of code motion, probably by making it look like a 
> call
> to an unknown function. No transform can reorder arbitrary 
> side-effects
> across such a call because doing so might change the apparent 
> semantics of
> the program. Similarly, if you need a direct use-def link between two
> points in the function, you should make the first point define a token
> that'll be used by the second point. No transform will break or 
> abstract
> that association because that would violate the basic structural rules 
> of IR.
> If there's a structural rule that can't be expressed with the current 
> tools
> of IR, we can talk about how to fix that --- although tokens are such 
> a big
> hammer that I'd be somewhat surprised to hear that something really 
> can't
> be expressed at all (but much less surprised to hear that the token 
> rules
> are too strong and we'd like other transforms to have more power to 
> change
> the code).
>
> 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.
>
> I like these conditions, in terms of bounding what this means.
>
> We might need to be more explicit about what moves code means, as 
> we're run into fuzzy lines before around inter-procedural 
> optimizations (e.g., return-value propagation, using the 'returned' 
> attribute, and variants). Would it work to say "move code with 
> potential side effects"?

That's a really good point.  Applying this to our current use-case, I'm 
pretty
sure that both return-value propagation and the `returned` attribute can 
break
Piotr's devirtualization optimization, so they need to intersect the 
caller's
list or clear it, respectively.  IIRC it used to be the case that 
`returned`
was mostly honored in the backend for liveness optimizations, i.e. long 
after
IR constructs like supported_optimizations have stopped being relevant, 
so
being very pessimistic about it is fine; but I don't know if that's 
still true.

John.


>
> Thanks again,
>
> Hal
>
> I think that answers your question about what sort of rules we can 
> expect
> supported_optimizations to guarantee.
>
> 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
>
>
> --
> Hal Finkel
> Lead, Compiler Technology and Programming Languages
> Leadership Computing Facility
> Argonne National Laboratory


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181204/b111bfa4/attachment.html>