<div dir="auto"><div><div class="gmail_quote"><div dir="ltr">On Fri, Oct 12, 2018, 10:33 David Greene via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Richard Smith via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" rel="noreferrer">cfe-dev@lists.llvm.org</a>> writes:<br>
<br>
> However, I do wonder: how is this different from, say, complex<br>
> numbers, for which we don't have a native IR representation? (Maybe<br>
> the answer is that we should have native IR support for complex<br>
> numbers too.)<br>
<br>
We've got at least one person here with decades of experience handling<br>
complex operations in compilers who thinks LLVM IR should absolutely<br>
have native support for complex, FWIW.  I don't have enough experience<br>
with it myself to make a definitive statement but I can certainly see<br>
advantages to it.<br>
<br>
Most of us here also think that LLVM IR should absolutely have native<br>
support for predication/masking.  :)<br></blockquote></div></div><div dir="auto">I can certainly agree.</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
As for matrices, I again can see the advantages but have no practical<br>
experience to draw upon.  But some people at Apple seem to think it's<br>
advantageous and I'm interested in learning more.<br>
<br>
                           -David<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div></div>