[LLVMdev] llvm.meta (was Rotated loop identification)

[Andrew Trick]

On Feb 7, 2013, at 10:58 PM, Hal Finkel <hfinkel at anl.gov> wrote:

>> As long as this is brainstorming time, I actually like the idea of an
>> llvm.invariant intrinsic that the optimizers know to ignore. I like
>> it for other purposes, but would happen to work for you as a
>> temporary workaround. It could take one or two IR values (as
>> metadata operands) and a metadata language describing the invariant,
>> such as a relational operator and optional constant. In your case,
>> you want to know that the loop counter's starting value is less than
>> its limit, so you could conveniently plop one of those in the loop
>> preheader. The invariant would only go away if no one else used the
>> value, which in your case would make sense (e.g. if the loop test
>> were rewritten in terms of %b, you probably wouldn't need the
>> invariant any more).
>> 
>> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20121210/158601.html
> 
> If you're in favor of this approach, can I pop out of the woodwork and say that it appears that we have a reasonably-large group of contributors in favor of an invariant intrinsic and we should move forward on that basis?

A general llvm.invariant does seem like a convenient thing. I'm not pushing very hard because I don't need it for anything I'm working on yet, and wasn't aware that anyone else liked this particular idea. But I haven't heard any argument against it. I am aware that a lot of people want to attach new semantics to the IR that are not necessarily easy to preserve, so I don't want to oversell a solution.

I don't have an opinion on whether each type of invariant should get its own intrinsic ID or we should have one and use the flexibility of metadata operands. The important thing is that the optimizer have a uniform approach to handling them, and that they truly cannot interfere with optimization other than as intended. For the sake of discussion, and to avoid confusion with the current, badly named llvm.invariant, I'll just call these llvm.meta intrinsics.

I would only endorse a new llvm.meta approach if we're sure we can unify or replace most of the current meta-style intrinsics. But I first need to better understand the motivation for those  approaches, which I have not personally worked with much (they're somewhat marginalized).

- llvm.dbg

  Are there any problems with our current approach?

- llvm.lifetime and llvm.invariant (for pointers)

  Why are they real value users? We probably don't care about extra
  users of an object base, but are we confident they won't affect
  optimization except as intended? I'd like to see an experiment where
  we emit these gratuitously, suppress optimizations that use them,
  strip them after -O3, and verify no effect on bitcode.

- llvm.annotation

  Does anyone use these? Supposedly the optimizer "ignores" them. But
  the optimizer certainly doesn't ignore additional uses of a value.

- llvm.expect

  This is injected in the def-use chain. Accidentally running the
  optimizer with these intrinsics present would be disasterous. It's
  really the same problem as representing an invariant, just different
  semantics.

- load range metadata

  We should be able to express general value ranges, independent of loads.
  We should be able to express the invariant conditionally, independent of the value's definition.
  The load's should be gvn-able without losing the invariants.

Future uses:

- Relating value to other values (not just a constant range).

- Pointer alignment.

- Pointers to immutable memory (when dominated by intrinsic).

You mentioned a number of other things you'd like to use invariants for in a previous post, I won't try to repeat them.

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