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

John McCall via cfe-dev cfe-dev at lists.llvm.org
Tue Dec 4 11:33:20 PST 2018

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 
> 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 
sure that both return-value propagation and the `returned` attribute can 
Piotr's devirtualization optimization, so they need to intersect the 
list or clear it, respectively.  IIRC it used to be the case that 
was mostly honored in the backend for liveness optimizations, i.e. long 
IR constructs like supported_optimizations have stopped being relevant, 
being very pessimistic about it is fine; but I don't know if that's 
still true.


> 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/cfe-dev/attachments/20181204/b111bfa4/attachment.html>

More information about the cfe-dev mailing list