[PATCH] D21534: GlobalISel: first outline of legalization interface.

[Eli Friedman via llvm-commits]

On Wed, Jun 22, 2016 at 1:16 PM, Quentin Colombet <qcolombet at apple.com>
wrote:

> Hi Tim,
>
> On Jun 22, 2016, at 9:16 AM, Tim Northover <t.p.northover at gmail.com>
> wrote:
>
> Hi Quentin,
>
> On 21 June 2016 at 11:58, Quentin Colombet <qcolombet at apple.com> wrote:
>
> I believe this is work in progress so I did not go into great details to
> comment on each part of the patch. For instance, for a detailed review, I
> would have expected the patch to be split into smaller one.
>
>
> Sure, I'll try to look for smaller independently testable bits.
>
> - I would split the file with the legalization APIs in two:
>  - one for the machine pass
>  - one for the helper
>
> The rationale is to be able to include them independently.
>
> - I would split the LegalizeHelper in two:
>  - One with all the methods you added (narrow, widen, etc), but legalize
>  - One with the legalize API and the set action stuff
>
>
> Yep, sounds compeltely reasonable.
>
> - Replace the Type/EVT by something lower level (Cf. my email)
>
> Basically, we do not need to know what are the types, we only need to know
> their size and there number of lanes, i.e., I would go with a different
> types representation for the MI level.
>
>
> I think we do need to know the the full types (at least MVT
> information) to decide on the correct action. <4 x float> could have
> very different requirements from <4 x i32>. I'm afraid I'm not sure
> what e-mail you're talking about either, do you have a link handy?
>
>
> I was talking of the offline discussion in "GISel - reality check"
>
> That’s just a remark in that email, the basic idea is what I said, I.e., I
> think we only need the size and number of lanes.
> Let me explain a bit why I think it is sufficient.
> <4 x float> and <4 x i32> are <4 x 32-bit> for most operations (load,
> store, and, shuffle, etc.). The only cases where that make a difference
> AFAICT are arithmetic operations. However, for those, the type is actually
> encoded in the opcode, e.g., fadd vs. add (we do not have G_FADD yet but I
> think we should :)). In other word, when type matters, the opcode should
> give us the information otherwise we should be able to get away of that
> business.
>
>
I'm not sure if this is really going to work the way you want. On x86 with
AVX (but not AVX2), is LOAD <8 x i32> legal?  I mean, you could declare
that it is... but you're going to end up with a bunch of vector shuffles
trying to legalize ADD <8 x i32>. You could clean it up afterwards with
some sort of optimization pass to split vectors where it's profitable...
but it gets complicated when you start dealing with values with multiple
uses and PHI nodes.

Whether it makes sense to distinguish <1 x i64> vs. i64 is a similar sort
of issue.

-Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160622/20b8f69c/attachment.html>