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

Chandler Carruth chandlerc at gmail.com
Wed Oct 15 16:41:26 PDT 2014


FWIW, I'd rather not use promotion here.

My inclination is to widen where doing so produces a legal type (and we
really need to have the ability to represent vNi1s as legal types in x86
even if we don't in AArch64), and scalarizing due to type illegality when
we can't widen to a legal type.

I suppose I would be OK doing promotion *once widening fails to find a
legal type* as a lowering? But from your description, it isn't clear that
this helps.

I actually agree that having v1 vector types be legal seems quite strange.
It would seem better to avoid that long-term if possible, and so I'd vote
for moving in a direction that at least doesn't make that harder?

On Wed, Oct 15, 2014 at 4:18 PM, Ahmed Bougacha <ahmed.bougacha at gmail.com>
wrote:

> 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
>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20141015/f8fa9001/attachment.html>


More information about the llvm-commits mailing list