[llvm-dev] LICM as canonical form

[Renato Golin via llvm-dev]

Hi Philip,

Like others, I like where this is going. Like all, I'm worried how much
weird stuff will come out of the box. :)

On Fri, 3 Dec 2021 at 23:27, Philip Reames via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Finally, to be explicit, I am using the SCEV use case by way of an example
> only.  There may be other ways that we depend on hoisting as a canonical
> form that I did not happen to think of when writing this email.  The burden
> is on the person or person proposing a change to identify any other
> dependencies, and to convince the community they have done so.  Discussion
> of a testing strategy to find those dependencies should be a first class
> concern in any proposal.
>

There are a number of checks in loop optimisations that look beyond SCEV,
and all of them will have to learn the new "canonical" forms.

What I mean is that wherever the ranges, loop dependencies, target
legalities will look at could have more than one shape (basically which BB
to look for it, how complex the Phi graph is, etc). It should not have to
look at *all* BBs in a given function nor build a complete graph of all
changes to all variables across all BBs accessible from the loop context.
So, perhaps we could propose at least two "canonical" forms (in quotes,
because it's more than one), but you get the idea.

Another issue is a potential cascading inability to perform
transformations. If there are passes between LICM and other loop
optimisations that happen to (perhaps implicitly) expect hoisted loads and
thus fail to transform in case the profiler says LICM shouldn't happen,
subsequent passes will have more and more "canonical" patterns to look for,
or more likely, will fail to see anything. The potential change to
everything that happens after LICM is worrying.

We already have that problem today, as probably all other compilers do, but
we have reached this local minimum by trial and error, and finding a better
minimum elsewhere will be an iterative process and likely pass through
maximums and create noise, especially in edge cases.

So the real question to me is: how are we going to guide this through the
solution space with minimal disruption while still making progress?

cheers,
--renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20211206/f0586ad0/attachment.html>