<div dir="ltr"><div dir="ltr">On Wed, Mar 27, 2019 at 4:40 PM Finkel, Hal J. <<a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 3/27/19 4:33 PM, Sebastian Pop via llvm-dev wrote:<br>
> I am of the opinion that handling scalable vectors (SV)<br>
> as builtins and an opaque SV type is a good option:<br>
><br>
> 1. The implementation of SV with builtins is simpler than changing the IR.<br>
><br>
> 2. Most of the transforms in opt are scalar opts; they do not optimize<br>
> vector operations and will not deal with SV either.<br>
><br>
> 3. With builtins there are fewer places to pay attention to,<br>
> as most of the compiler is already dealing with builtins in<br>
> a neutral way.<br>
><br>
> 4. The builtin approach is more targeted and confined: it allows<br>
> to amend one optimizer at a time.<br>
> In the alternative of changing the IR, one has to touch all the<br>
> passes in the initial implementation.<br>
<br>
<br>
Interestingly, with similar considerations, I've come to the opposite<br>
conclusion. While in theory the intrinsics and opaque types are more<br>
targeted and confined, this only remains true *if* we don't end up<br>
teaching a bunch of transformations and analysis passes about them.<br></blockquote><div><br></div><div>While I continue to disagree with Hal about whether we want this at all, FWIW I agree on this specific point.</div><div><br></div><div>*If* we are going to end up teaching a bunch of transformations about these, I think it will in many case be preferable to have them in the IR.</div><div><br></div><div>Using intrinsics and an opaque type, IMO, makes the most sense as a pass-through mechanism for allowing very limited usage without investing in any significant mid-level analysis or transformation awareness.</div><div><br></div><div>-Chandler</div></div></div>