<div dir="ltr"><div class="gmail_default"><font face="arial, helvetica, sans-serif">Can you tell us what you're looking to do with the intrinsics?</font></div><div class="gmail_default"><font face="arial, helvetica, sans-serif"><br></font></div><div class="gmail_default"><font face="arial, helvetica, sans-serif">On all non-AArch64 targets the ExpandReductions pass will convert them to the shuffle pattern as you're seeing. That pass was written in order to allow experimentation of the effects of using reduction intrinsics at the IR level only, hence we convert into the shuffles very late in the pass pipeline.</font></div><div class="gmail_default"><font face="arial, helvetica, sans-serif"><br></font></div><div class="gmail_default"><font face="arial, helvetica, sans-serif">Since we haven't seen any adverse effects of representing the reductions as intrinsics at the IR level, I think in that respect the intrinsics have probably proven themselves to be stable. However the error you're seeing is because the AArch64 backend still expects to deal with only intrinsics it can *natively* support, and i1 is not a natively supported type for reductions. See the code in AArch64TargetTransformInfo.cpp:useReductionIntrinsic() for where we decide which reduction types we can support.</font></div><div class="gmail_default"><font face="arial, helvetica, sans-serif"><br></font></div><div class="gmail_default"><font face="arial, helvetica, sans-serif">For these cases, we need to implement more generic legalization support in order to either promote to a legal type, or in cases where the target cannot support it as a native operation at all, to expand it to a shuffle pattern as a fallback. Once we have all that in place, I think we're in a strong position to move to the intrinsic form as the canonical representation.</font></div><div class="gmail_default"><font face="arial, helvetica, sans-serif"><br></font></div><div class="gmail_default"><font face="arial, helvetica, sans-serif">FYI one of the motivating reasons for these to be introduced was to allow non power-of-2 vector architectures like SVE to express reduction operations.</font></div><div class="gmail_default"><font face="arial, helvetica, sans-serif"><br></font></div><div class="gmail_default"><font face="arial, helvetica, sans-serif">Amara</font></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 4 August 2017 at 13:36, Haidl, Michael <span dir="ltr"><<a href="mailto:michael.haidl@uni-muenster.de" target="_blank">michael.haidl@uni-muenster.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Renato,<br>
<br>
just to make it clear, I didn't implement reductions on x86_64 they just<br>
worked when I tried to lower an<br>
llvm.experimentel.vector.<wbr>reduce.or.i1.v8i1 intrinsic. A shuffle pattern<br>
is generated for the intrinsic.<br>
<br>
        vpshufd $78, %xmm0, %xmm1       # xmm1 = xmm0[2,3,0,1]<br>
        vpor    %xmm1, %xmm0, %xmm0<br>
        vpshufd $229, %xmm0, %xmm1      # xmm1 = xmm0[1,1,2,3]<br>
        vpor    %xmm1, %xmm0, %xmm0<br>
        vpsrld  $16, %xmm0, %xmm1<br>
        vpor    %xmm1, %xmm0, %xmm0<br>
        vpextrb $0, %xmm0, %eax<br>
<br>
<br>
However, on AArche64 I encountered an unreachable where codegen does not<br>
know how to promote the i1 type. Since I am more familiar with the<br>
midlevel I have to start digging into codegen. Any hints where to start<br>
would be awesome.<br>
<br>
Cheers,<br>
Michael<br>
<div class="HOEnZb"><div class="h5"><br>
Am 04.08.2017 um 08:18 schrieb Renato Golin:<br>
> On 3 August 2017 at 19:48, Haidl, Michael via llvm-dev<br>
> <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
>> thank you for the clarification. I tested the intrinsics x86_64 and it<br>
>> seemed to work pretty well. Looking forward to try this intrinsics with<br>
>> the AArch64 backend. Maybe I find the time to look into codegen to get<br>
>> this intrinsics out of experimental stage. They seem pretty useful.<br>
><br>
> In addition to Amara's point, it'd be good to have it working and<br>
> default for other architectures before we can move out of experimental<br>
> if we indeed intend to make it non-arch-specific (which we do).<br>
><br>
> So, if you could share your code for the x86 port, that'd be great.<br>
> But if you could help with the final touches on the code-gen part,<br>
> that'd be awesome.<br>
><br>
> cheers,<br>
> --renato<br>
><br>
</div></div></blockquote></div><br></div>