<div dir="ltr">FWIW, I'd rather not use promotion here.<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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?</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 15, 2014 at 4:18 PM, Ahmed Bougacha <span dir="ltr"><<a href="mailto:ahmed.bougacha@gmail.com" target="_blank">ahmed.bougacha@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Hao, Chandler, and Tim,<br>
<br>
This seems to be "causing" [[ <a href="http://llvm.org/bugs/show_bug.cgi?id=20778" target="_blank">http://llvm.org/bugs/show_bug.cgi?id=20778</a> | PR20778 ]] : by widening v1i{32,16,8}, this pushes the original problem (scalarizer asserting because the trunc operand wasn't scalarized) to v1i1.<br>
There was a similar problem for setcc+vselect, cf. r205625.<br>
>From what I see, there are a variety of possible solutions:<br>
<br>
1- The obvious way is to also widen v1i1. However, widening wouldn't result in any legal type.<br>
<br>
2- Promote v1i1, to v1i64. This produces a few (correct) changes (visible in test/CodeGen/AArch64/aarch64-neon-v1i1-setcc.ll).<br>
Also, there is a long-standing FIXME regarding the issue:<br>
<br>
  // FIXME: Currently the type legalizer can't handle VSELECT having v1i1 as<br>
  // condition. If it can legalize "VSELECT v1i1" correctly, no need to combine<br>
  // such VSELECT.<br>
<br>
Promoting v1i1 somewhat fixes this: we still need combining, but to avoid using v1i64 instead of i64 for vselect+setcc.<br>
<br>
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.<br>
<br>
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.<br>
<br>
<br>
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.<br>
<br>
I have a few patches to implement the promotion, but that's problematic, because it then breaks the legalizer on this kind of input:<br>
<br>
  %rhs_t = trunc <1 x i16> %rhs to <1 x i1><br>
<br>
<br>
What do you think? I can put my experimental patches for #2 on phabricator if desired.<br>
<br>
Thanks!<br>
<span class="HOEnZb"><font color="#888888">-Ahmed<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<a href="http://reviews.llvm.org/D4322" target="_blank">http://reviews.llvm.org/D4322</a><br>
<br>
<br>
<br>
_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
</div></div></blockquote></div><br></div>