[llvm-dev] Writing loop transformations on the right representation is more productive

[Renato Golin via llvm-dev]

On Wed, 15 Jan 2020 at 04:39, Michael Kruse <llvmdev at meinersbur.de> wrote:
> As I recall, the Parallel IR approaches were trying to add parallel constructs to the existing LLVM-IR. This added the issue that the current infrastructure suddenly need to handle those as well, becoming a major problem for adoption.

Yes, and that's why we could never agree on the one representation. A
completely separate one solves that problem, but introduces another,
itself.


> I see it as an advantage in respect of adoption: It can be switched on and off without affecting other parts.

That's not necessarily true.

If we do like Polly, it is, but then the ability to reuse code is very
low and the time spent converting across is high. If we want to reuse,
then we'll invariably add behavioural dependencies and disabling the
pass may have side-effects.


> Versioning is always a trade-off between how likely the preconditions apply and code size (and maybe how expensive the runtime checks are). IMHO this concern is separate from how code versioning is implemented.

Agreed.


> Agreed, but IMHO this is the price to pay for better loop optimizations.

This may be true, and I can easily accept that, as long as we'll all
aware of the costs of doing so up front.


> I'd put loop optimizations earlier into the pipeline than vectorization. Where exactly is a phase ordering problem. I'd want to at least preserve multi-dimensional subscripts. Fortunately MemRef is a core MLIR construct and unlikely to be lowered before lowering to another representation (likely LLVM-IR).

Many front-ends do that even before lowering to IR because of the
richer semantics of the AST, but it's also common for that to
introduce bugs down the line (don't want to name any proprietary
front-ends here).

I agree moving high-level optimisation passes up and doing so in a
high-level IR is a good idea.


> I don't see how this is relevant for a Clang-based pipeline. Other languages likely need a different pipeline than one intended for C/C++ code.

Yes, but we want our passes to work for all languages and be less
dependent on how well they lower their code.

If they do it well, awesome. If not, and if we can identify patterns
in LLVM IR then there is no reason not to.

cheers,
--renato