<div dir="ltr">Hi Craig,<div><br></div><div>Thank you very much for your answer.</div><div><br></div><div>I did not want to discuss exactly the semantic and name of one operation but instead raise the question "would it be beneficial to have more vector builtins?".</div><div><br></div><div>You wrote that the compiler will recognize a pattern and replace it by __builtin_ia32_haddps when possible, but how can I be sure of that? I would have to disassemble the generated code right? It is very impractical isn'it? And it leads me to understand that each CPU target has a bank of patterns which it can recognize but wouldn't it be very similar to have advanced generic vector operations and CPU specific implementation for those builtins?</div><div><br></div><div>Regarding hadd; I agree, the name does not very well describe what it is doing. And yes hadd could be summing all the vector elements, but I think that the usual terminology for that is reduce_add.</div><div><br></div><div>In my case I use it for computing the mono signal of a stereo interleaved signal:</div><div><br></div><div>a = load(in);</div><div>b = load(in + K);</div><div>l = suffle(a, b, 0, 2, 4, 6, ...); // l and r have the same size as a</div><div>r = suffle(a, b, 1, 3, 5, 7, ...);</div><div>m = .5 * (l + r); // m has the same size as a and b which is maybe optimal for memory I/O?</div><div>store(m, out);</div><div><br></div><div>As you said it, I could have m being half of the size of a, and I would not need to load b. Which approach would deliver the best performance? Does the compiler recognize both? Maybe there is another valid approach, will the compiler recognize it?</div><div><br></div><div>I would like also to discuss reduce_add, there might be multiple ways of doing it right but is there one that is faster? Is the same approach always the best or it depends on the CPU? I believe that those questions are best answered by the compiler.</div><div><br></div><div>Then some side-notes regarding clang documentation __builtin_shufflevector is not referenced there <a href="https://clang.llvm.org/docs/LanguageExtensions.html#vectors-and-extended-vectors">https://clang.llvm.org/docs/LanguageExtensions.html#vectors-and-extended-vectors</a></div><div><br></div><div>Best regards,</div><div>Alexandre Bique<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Aug 19, 2020 at 8:34 PM Craig Topper <<a href="mailto:craig.topper@gmail.com">craig.topper@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>I'm not sure everyone would agree that the behavior of a __builtin_vector_hadd should do what the X86 instruction does. It takes two vectors and produces a result with elements from both vectors. Someone might argue that a horizontal add should just take one source and produce a vector with half the number of elements. Someone else might argue that a horizontal add should sum all the elements to a single scalar value. With different implementation choices like that its hard to say it should be a generic operation when the behavior might only make sense for one target's instruction set.</div><div><br></div><div>The behavior of the 256-bit vhaddps instruction on X86 is also weird since it treats the upper and lower 128-bits of the sources and destination independently. That quirk wouldn't make sense in a generic operation.</div><div><br></div><div>You can emulate __builtin_ia32_haddps generically using __builtin_shufflevector and the + operator. The X86 backend should recognize it and use haddps.</div><div><br></div><div><div dir="ltr">~Craig</div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Aug 19, 2020 at 10:54 AM Alexandre Bique via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi,</div><div><br></div><div>I love llvm vectors, yet I wonder why some advanced vector operations are specific to some CPU targets?</div><div><br></div><div>Let me take an example:</div><div><br></div>/// Horizontally adds the adjacent pairs of values contained in two<br>/// 128-bit vectors of [4 x float].<br>///<br>/// \headerfile <x86intrin.h><br>///<br>/// This intrinsic corresponds to the <c> VHADDPS </c> instruction.<br>///<br>/// \param __a<br>/// A 128-bit vector of [4 x float] containing one of the source operands.<br>/// The horizontal sums of the values are stored in the lower bits of the<br>/// destination.<br>/// \param __b<br>/// A 128-bit vector of [4 x float] containing one of the source operands.<br>/// The horizontal sums of the values are stored in the upper bits of the<br>/// destination.<br>/// \returns A 128-bit vector of [4 x float] containing the horizontal sums of<br>/// both operands.<br>static __inline__ __m128 __DEFAULT_FN_ATTRS<br>_mm_hadd_ps(__m128 __a, __m128 __b)<br>{<br> return __builtin_ia32_haddps((__v4sf)__a, (__v4sf)__b);<br>}<br><div><br></div><div>Here clang will translate _mm_hadd_ps to a CPU specific feature.</div><div>Why not create __builtin_vector_hadd(a, b) which would select the CPU specific instruction or a fallback generic implementation?</div><div><br></div><div>Many thanks,</div><div>Alex</div></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>
</blockquote></div>