[llvm-commits] [PATCH] Invariants (and Assume Aligned) - LLVM

[Dan Gohman]

On Wed, Dec 5, 2012 at 8:15 PM, Hal Finkel <hfinkel at anl.gov> wrote:
>>
>> Note that this approach doesn't automatically eliminate the problem
>> of
>> anchoring the intrinsic with respect to the surrounding control flow
>> and side effects. Presumably, it would still be useful to let the
>> intrinsic appear to have side effects to achieve this, as it does in
>> the current patch. That will interfere with GVN, DSE, LICM, and many
>> other optimizations, but these problems can be special-cased around.
>
> The objections to my first patch, which was implemented along these lines, was that there were too many special cases (even in that patch, and I had only touched some of them). In some sense, doing this implements a new kind of bitcast (albeit one with which it is less convenient to work). On the other hand, perhaps my original patch simply had a lot of special cases without a sufficient upside (being that it applied only to the alignment case). With invariants, the cost/benefit analysis might be different.
>
> To propose an alternative, we could consider the invariant to be solely a frontend matter, and lower as:
>
> (things before)
> __builtin_assume(x);
> (things after)
>
> as
>
> (things before)
> if (x) {
>   (things after)
> } else
>   unreachable;
>
> This, of course, may have its own issues ;)

This is, of course, not a new idea, and it does indeed have its own issues ;-).

>> so they can hold early loop exits ephemerally live, which means they
>> could complicate loop optimization. It's a design principle in LLVM
>> that the main middle-end optimizations work to enable other
>> optimizations. Introducing artificial constructs which hold values
>> and
>> branches and stores live interferes with this in a very philosophical
>> way.
>
> You're right; and having the invariants could certainly interfere with optimization. One way of looking at it is this: Representing the invariant using IR will naturally keep the invariant itself from being optimized away. This is a good thing when the invariant is assisting with "large" optimizations: higher-level loop transformations, autovectorization, conditional-branch short-circuiting, etc. This is probably not a good thing after those kinds of transformations have run and we're more concerned with lower-level transformations. A good trade-off may be that at some point, unless we're doing LTO, we should drop the invariants.

Another perspective is that many of these higher-level optimizations
are naturally fragile, and so it's important to do as much clean-up
and canonicalization optimization as possible before they run, to give
the high-level passes the best opportunity possible.

Dan