[llvm-dev] [RFC] Allow loop vectorizer to choose vector widths that generate illegal types

[Renato Golin via llvm-dev]

On 22 June 2016 at 19:00, Michael Kuperstein <mkuper at google.com> wrote:
> How common is the "LoopVectorizer + FastISel + Performance is important"
> use-case?

Ah, I didn't mean that FastIsel would be a problem here.

FastIsel was an attempt to re-write the selection DAG but it wasn't
activated to all cores / ISAs and now it'll probably never be used for
Thumb on ARM (sorry, context).

I don't want this to happen with the vectorizer, and have two
completely different default behaviours that can span all the way down
the codegen level, or it would be a nightmare to implement, test and
benchmark anything.


> Then we can move the per-platform defaults to either the "regular" or the
> "harder" versions independently. Is this what you meant? If so, it makes
> perfect sense to me.

Sort of, yes. But also in the sense of pushing the changes through the
back-end. Example:

Step1: enable larger sizes for types X, teach legalizeTypes to do that one.
Step2: enable it for type Y, change legalizer, fix coge gen bug B1
Step3: refactor selDAG for target T1 a bit, prepare the Greedy regalloc
Step4: enable T1's X, change legalizer
etc...

So, if we could selectively enable this for certain types on certain
targets (say, single-FP on ARM), then we'll be able to progress and
refactor as we go along, without the *need* to finish everything in
less than six months to make it into the next release.


> I agree this is a problem, but it seems like it should be orthogonal to what
> I'm suggesting. I probably don't understand the background well enough,
> though.

It should be more orthogonal than it is, really. The cost model has a
lot of heuristics about how we *think* the IR pattern X will lower
into the <Target> instructions Y, and some of those costs were fudged
into submission by trial and error.

As we start changing the costs, or worse, the cost model, we can
completely derail some problematic cases. If we're not looking for
those, we'd only realise months later, on release benchmarking... :(


> That wold be great! I'm going to start with X86, mostly because that's the
> platform I'm most familiar with. But once it works on X86 (hopefully), I'll
> definitely need help with other platforms, both in terms of the cost model
> and benchmarking.

Makes sense.

If I have some time, early on, I want to try your x86 patches and
enable them for ARM, just to see the world crumble. :)

cheers,
--renato