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

Tim Northover via llvm-commits llvm-commits at lists.llvm.org
Wed Jun 22 09:13:30 PDT 2016


On 20 June 2016 at 15:13, Eli Friedman <eli.friedman at gmail.com> wrote:
> I'm not sure ScalarInVectorActions covers all the possibilities for legalization... for example, x86 prefers to legalize `<4 x i16>` to `<4 x i32>` rather than `<8 x i16>`.

In the general case, I think we're probably going to prefer the latter
(or at least give MoreElements-by-default a chance). In this specific
case you could model it with a specific setAction(G_ADD, MVT::v4i16,
WidenScalar).

That might get unwieldy though, so I'll think some more on the issue.

> It isn't clear how you plan on dealing with soft-float; for certain operations, like FABS, you probably want a separate "soften" action (so you can convert f64 FABS -> i64 AND -> i32 AND).

Agreed, I'd not gotten around to thinking about soft-float yet.

> You really need to work out what to do with operations with multiple types sooner rather than later, given how common they are.  The existing legalization infrastructure basically splits it into multiple steps: first legalize the result type, then legalize each operand type.

I'm sure they'll crop up pretty soon, so I'm not that worried about
forcing it into the first patch. I'm not really convinced by the
res/op distinction though (cmpxchg is the obvious example where it
breaks down, and intrinsics if we allow them to be legalized in the
new scheme).

> For `<1 x i64>` vs. `i64`, the distinction is a bit fuzzy... but I'm not sure we can really afford to throw it away.  We're currently pretty comfortable with the distinction that `<1 x i64>` uses vector registers if possible, and `i64` doesn't.

I think that's pretty widely viewed as a mistake, or at least a hack
based on the limited resources we had in ISelDAG. The reg-bank select
should be making those decisions based on surrounding uses of the
value.

> Doing something different gets very complicated on x86-32 and other similar architectures because we would need to "legalize" i64 operations after register bank assignment.

Part of the goal here is to be able to legalize at any stage if
necessary (hence the split into a helper and a pass).

> You need some legalization action equivalent to "LegalizeDAG", I think.  Do you have something planned?

Are you viewing this as replacing only LegalizeTypes? In the new view
of the world, basically any type that can be loaded or stored is
"legal" so the distinction is much smaller.

Cheers.

Tim.


More information about the llvm-commits mailing list