[PATCH] [AArch64] Change default legalization behavior of v1i32 to be widen to v2i32 instead of scalarization

[Ahmed Bougacha]

Hi Hao, Chandler, and Tim,

This seems to be "causing" [[ http://llvm.org/bugs/show_bug.cgi?id=20778 | PR20778 ]] : by widening v1i{32,16,8}, this pushes the original problem (scalarizer asserting because the trunc operand wasn't scalarized) to v1i1.
There was a similar problem for setcc+vselect, cf. r205625.
>From what I see, there are a variety of possible solutions:

1- The obvious way is to also widen v1i1. However, widening wouldn't result in any legal type.

2- Promote v1i1, to v1i64. This produces a few (correct) changes (visible in test/CodeGen/AArch64/aarch64-neon-v1i1-setcc.ll).
Also, there is a long-standing FIXME regarding the issue:

  // FIXME: Currently the type legalizer can't handle VSELECT having v1i1 as
  // condition. If it can legalize "VSELECT v1i1" correctly, no need to combine
  // such VSELECT.

Promoting v1i1 somewhat fixes this: we still need combining, but to avoid using v1i64 instead of i64 for vselect+setcc.

3- Change the generic legalizer logic to not assert, when an operation's operands haven't been legalized before (in this case the scalarizer expecting v1i64 to be transformed to i64). This was also done in r205625, but is a pretty ugly hack.

4- Make v1i64 not legal. I'm not sure why it is legal in the first place: why not scalarize to i64? This doesn't seem like a trivial change though. However, making v1i64 and v1f64 non-legal would cleanup a few parts of the AArch64 backend.


Also, a general problem with most of these is that v1i1 isn't a SimpleVT, and most of the legalizer logic is based on (enum SimpleVT)-indexed arrays. Adding v1i1 doesn't make perfect sense (it's not really legal on any target), but it seems sensible enough.

I have a few patches to implement the promotion, but that's problematic, because it then breaks the legalizer on this kind of input:

  %rhs_t = trunc <1 x i16> %rhs to <1 x i1>


What do you think? I can put my experimental patches for #2 on phabricator if desired.

Thanks!
-Ahmed

http://reviews.llvm.org/D4322