[llvm-dev] [GlobalISel] A Proposal for global instruction selection

[Krzysztof Parzyszek via llvm-dev]

On 11/19/2015 6:58 PM, Eric Christopher via llvm-dev wrote:
> It'll be interesting to see how this is going to be developed and how to
> keep the target independentness of the code generator with this new
> scheme. I.e. this is basically turning (in my mind) into "every backend
> for themselves" with very little target independent unification.

I really don't mind the "every backend for themselves" approach.  The 
instruction selection pass is about as target-specific as a common pass 
can get, and the more work the generic code tries to do, the more 
potential it has to be inflexible.  This is not to say that a generic 
code will necessarily be bad, but that a target-centric approach has a 
better chance of working out better, even if it means that more work is 
required to implement instruction selection for a new target.

As someone mentioned in another email, the canonicalization currently 
done in the DAG combiner has a tendency to interfere with what 
individual targets may prefer.  One example of it that I remember for 
Hexagon was that the LLVM IR had a combination of shifts left and right 
to extract a bitfield from a longer integer.  Hexagon has an instruction 
to do that and it's quite simple to map the shifts into that 
instruction.  The combiner, hovewer, would fold the shifts leaving only 
the minimum sequence of operations necessary to get the bitfield.  This 
seems to be better from the generic point of view, but it makes it 
practically impossible for us to match it to the "extract" instruction, 
and in practice the code turns out to be worse.  This is the only reason 
why we have the HexagonGenExtract pass---we detect the patterns in the 
LLVM IR and generate "extract" intrinsics before the combiner mangles 
them up into unrecognizable forms.  The same goes for replacing ADD with 
OR when the bits in the operands do not overlap.  We have code that 
specifically undoes that, since for us, if the original code had an ADD, 
it is pretty much always better if it remains an ADD.

There were cases in the past when we had to disable parts of 
CodeGenPrepare, or else it would happily promote i32 into i64 where it 
wasn't strictly necessary.  I64 is a legal type on Hexagon, but it uses 
pairs of registers which, in practical terms, means that our register 
set is cut by half when 64-bit values are used.

On the other hand, having a relatively simple, generic IR makes it 
easier to simplify code that is no longer subjected to the LLVM IR's 
constraints (e.g. getelementptr expressed as +/*, etc.).  Hexagon has a 
lot of very specific complex/compound instructions and a given code can 
be written in many different ways.  This makes it harder to optimize 
code after the specific instructions have been selected.  For example, a 
pass that would try to simplify arithmetic code would need to deal with 
the dozens of variants of add/multiplication instructions, instead of 
simply looking at some generic GADD/GMPY.

-Krzysztof

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
hosted by The Linux Foundation