<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">[re-sending to list with new email]</span><div class=""><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""><br class=""></span></div><div class=""><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">Ping. As far as I can tell the remaining issues are solved?</span><div class="" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><br class=""></div><div class="" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">If so, we’ll need to duplicate the intrinsics without the “experimental”, and add support in the IR autoupgrader and fix up the tests.</div><div class="" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><br class=""></div><div class="" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">Amara</div><div><br class=""><blockquote type="cite" class=""><div class="">On Sep 9, 2020, at 9:37 AM, Sanjay Patel <<a href="mailto:spatel@rotateright.com" class="">spatel@rotateright.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">Proposal to specify semantics for the FP min/max reductions:</div><div class=""><a href="https://reviews.llvm.org/D87391" class="">https://reviews.llvm.org/D87391</a></div><div class="">I'm not sure how we got to the current state of codegen for those, but it doesn't seem consistent or correct as-is, so I've proposed updates there too.<br class=""></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 17, 2020 at 2:15 PM Amara Emerson via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;" class="">Proposed clarification here: <a href="https://reviews.llvm.org/D82034" target="_blank" class="">https://reviews.llvm.org/D82034</a><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Jun 17, 2020, at 5:52 AM, Simon Pilgrim via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><br class=""><div class="">
<div class=""><p class="">A minor point, but I think we need to more explicitly describe
the order of floating point operations in the LangRef as well:<br class="">
</p><p class="">"If the intrinsic call has the ‘reassoc’ or ‘fast’ flags set,
then the reduction will not preserve the associativity of an
equivalent scalarized counterpart. Otherwise the reduction will be
ordered, thus implying that the operation respects the
associativity of a scalarized reduction."</p><p class="">Please could we add some pseudocode to show exactly how the
intrinsic will be re-expanded for ordered cases?<br class="">
</p>
<div class="">On 16/06/2020 19:38, Sanjay Patel via
llvm-dev wrote:<br class="">
</div>
<blockquote type="cite" class="">
<div dir="ltr" class="">
<div class="">We switched over to producing the intrinsics for x86 with:<br class="">
</div>
<div class=""><a href="https://reviews.llvm.org/rGe50059f6b6b3" rel="noreferrer" target="_blank" class="">https://reviews.llvm.org/rGe50059f6b6b3</a></div>
<div class="">...I'm not aware of any regressions yet.</div>
<div class=""><br class="">
</div>
<div class=""><a href="https://bugs.llvm.org/show_bug.cgi?id=45378" rel="noreferrer" target="_blank" class="">https://bugs.llvm.org/show_bug.cgi?id=45378</a>
is also fixed as of today.</div>
<div class=""><br class="">
</div>
<div class="">So that leaves the problem with fmin/fmax when no
fast-math-flags are specified. We need to update the LangRef
with whatever the expected behavior is for NaN and -0.0. <br class="">
</div>
<div class="">x86 will probably be poor regardless of whether we choose
"llvm.maxnum" or "llvm.maximum" semantics.<br class="">
</div>
</div>
<br class="">
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, Apr 9, 2020 at 1:28 PM
Craig Topper via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a>>
wrote:<br class="">
</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" class="">No we still use the shuffle expansion which is
why the issue isn't unique to the intrinsic.
<div class=""><br clear="all" class="">
<div class="">
<div dir="ltr" class="">~Craig</div>
</div>
<br class="">
</div>
</div>
<br class="">
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, Apr 9, 2020 at
10:21 AM Amara Emerson <<a href="mailto:aemerson@apple.com" target="_blank" class="">aemerson@apple.com</a>> wrote:<br class="">
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="">Has x86 switched to the intrinsics now?
<div class="">
<div class=""><br class="">
<blockquote type="cite" class="">
<div class="">On Apr 9, 2020, at 10:17 AM, Craig Topper
<<a href="mailto:craig.topper@gmail.com" target="_blank" class="">craig.topper@gmail.com</a>>
wrote:</div>
<br class="">
<div class="">
<div dir="ltr" class="">
<div class="">That recent X86 bug isn't unique to the
intrinsic. We generate the same code from
this which uses the shuffle sequence the
vectorizers generated before the reduction
intrinsics existed.<br class="">
<br class="">
</div>
<div class="">declare i64
@llvm.experimental.vector.reduce.or.v2i64(<2
x i64>)·<br class="">
declare void @TrapFunc(i64)<br class="">
<br class="">
define void @parseHeaders(i64 * %ptr) {<br class="">
%vptr = bitcast i64 * %ptr to <2 x
i64> *<br class="">
%vload = load <2 x i64>, <2 x
i64> * %vptr, align 8<br class="">
<br class="">
%b = shufflevector <2 x i64> %vload,
<2 x i64> undef, <2 x i32>
<i32 1, i32 undef><br class="">
%c = or <2 x i64> %vload, %b<br class="">
%vreduce = extractelement <2 x i64>
%c, i32 0<br class="">
<br class="">
%vcheck = icmp eq i64 %vreduce, 0<br class="">
br i1 %vcheck, label %ret, label %trap<br class="">
trap:<br class="">
%v2 = extractelement <2 x i64>
%vload, i32 1<br class="">
call void @TrapFunc(i64 %v2)<br class="">
ret void<br class="">
ret:<br class="">
ret void<br class="">
}<br class="">
</div>
<br clear="all" class="">
<div class="">
<div dir="ltr" class="">~Craig</div>
</div>
<br class="">
</div>
<br class="">
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, Apr
9, 2020 at 10:04 AM Philip Reames via
llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a>>
wrote:<br class="">
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">My
experience with them so far is that the code
generation for these <br class="">
intrinsics is still missing a lot of cases.
Some of them are X86 <br class="">
specific (the target I look at mostly), but
many of them have generic forms.<br class="">
<br class="">
As one recent example, consider <br class="">
<a href="https://bugs.llvm.org/show_bug.cgi?id=45378" rel="noreferrer" target="_blank" class="">https://bugs.llvm.org/show_bug.cgi?id=45378</a>.
(There's nothing special <br class="">
about this one other than it was recent.)<br class="">
<br class="">
I'm not necessarily arguing they can't be
promoted from experimental, <br class="">
but it would be a much easier case if the
code gen was routinely as good <br class="">
or better than the scalar forms. Or to say
that a bit differently, if <br class="">
we could canonicalize to them in the IR
without major regression. <br class="">
Having two ways to represent something in
the IR without any agreed upon <br class="">
canonical form is always sub-optimal.<br class="">
<br class="">
Philip<br class="">
<br class="">
On 4/7/20 9:59 PM, Amara Emerson via
llvm-dev wrote:<br class="">
> Hi,<br class="">
><br class="">
> It’s been a few years now since I added
some intrinsics for doing vector reductions.
We’ve been using them exclusively on
AArch64, and I’ve seen some traffic a while
ago on list for other targets too. Sander
did some work last year to refine the
semantics after some discussion.<br class="">
><br class="">
> Are we at the point where we can drop
the “experimental” from the name? IMO all
target should begin to transition to using
these as the preferred representation for
reductions. But for now, I’m only proposing
the naming change.<br class="">
><br class="">
> Cheers,<br class="">
> Amara<br class="">
>
_______________________________________________<br class="">
> LLVM Developers mailing list<br class="">
> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a><br class="">
> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank" class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br class="">
_______________________________________________<br class="">
LLVM Developers mailing list<br class="">
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a><br class="">
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank" class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br class="">
</blockquote>
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
</blockquote>
</div>
_______________________________________________<br class="">
LLVM Developers mailing list<br class="">
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a><br class="">
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank" class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br class="">
</blockquote>
</div>
<br class="">
<fieldset class=""></fieldset>
<pre class="">_______________________________________________
LLVM Developers mailing list
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank" class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
</blockquote>
</div>
_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a><br class=""><a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank" class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br class=""></div></blockquote></div><br class=""></div>_______________________________________________<br class="">
LLVM Developers mailing list<br class="">
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a><br class="">
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank" class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br class="">
</blockquote></div>
</div></blockquote></div><br class=""></div></body></html>