RFC: min/max/abs IR intrinsics

Renato Golin renato.golin at linaro.org
Tue Apr 28 09:31:24 PDT 2015


On 28 April 2015 at 16:53, James Molloy <james at jamesmolloy.co.uk> wrote:
>   * Philip Reames favours late matching, where we create intrinsics late in
> the optimization pipeline (CodeGenPrepare) and use "select" as the canonical
> form up till that point.
>   * Owen Anderson favours early matching, using min/max intrinsics as the
> canonical form through most of the compiler.
>
> Consensus hasn't yet been reached. Thoughts?

Hi James,

A similar discussion spawned regarding indexed / strided / masked
memory access and the risks are the same:

* Early matching hardens the IR, stopping a lot of optimisations working
* Late matching allows for scrambled IR (due to unaware
optimisations), and destroy patterns

Each one is horrible in their own right, but I'll side with Philip in
this one, in the same way I think Chandler was right about doing more
to match complex memory accesses in pure IR, even if the patterns do
get more complex. My reasons are two fold:

1. I'll repeat Philip's words: Where do we stop? How many intrinsics
are we going to add to the IR until every optimisation pass becomes a
huge switch with all possible variations? This was the original design
decision behind not implementing every NEON intrinsic as a builtin
node, and I still believe Bob Wilson was right back then. It did
generate better code.

2. It's easier to fix the passes that destroy data, even if there are
many of them, than to add all builtins to all passes in order to
understand IR. I agree, doing so doesn't scale well, especially if you
move to a dynamic execution of passes (if the pass manager ever
supports that), but the alternative doesn't scale at all. It's
polynomial vs. exponential. Both are bad, but exponential is worse.

In the end, for the strided loads, Hao decided to try out plain IR,
shuffles and loads/stores. Elena will try too, for masked and indexed
loads, and only as a last resort, we'll add those intrinsics. There
were some added, and if possible, we should remove them if we succeed
in matching enough patters with just IR.

I think we should do the same in this case.

cheers,
--renato



More information about the llvm-commits mailing list