<div dir="ltr"><div dir="ltr">On Tue, Mar 19, 2019 at 4:11 AM Graham Hunter <<a href="mailto:Graham.Hunter@arm.com">Graham.Hunter@arm.com</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">Hi Eric and Chandler,<br>
<br>
I appreciate your concerns; I don't think the impact will be that great, but then it's<br>
rather easy for me to keep SVE in mind when working on other parts of the codebase<br>
given how long I've spent working on it.<br>
<br>
Are there any additional constraints on the scalable types you think would alleviate<br>
your concerns a little? At the moment we will prevent scalable vectors from being<br>
included in structs and arrays, but we could add more (at least to start with) to<br>
avoid potential hidden problems.<br></blockquote><div><br></div><div>While the constraints you mention are good, and important, I don't think there are more that matter.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I'm also trying to come up with an idea of how much impact we have in our downstream<br>
implementation; most places where there is divergence are in the AArch64 backend (as you'd<br>
expect), followed by the generic SelectionDAG code -- but lowering and legalization for<br>
current instructions should (hopefully) be a one-off.<br>
<br>
Do you have any specific parts of the codebase you're interested in a report into the<br>
extent of changes?<br></blockquote><div><br></div><div>This is *not* about the changes required. It is about the long term (think 10-years) complexity forced onto the IR.</div><div><br></div><div>We now have vectors that are unlike *all other vectors* in the IR. They're basically unlike all other types. I believe we will be finding bugs with this special case ~forever. Will it be an untenable burden? Definitely not. We can manage.</div><div><br></div><div>But the question is: does the benefit outweigh the cost? IMO, no.</div><div><br></div><div>I completely understand the benefit of this for the *ISA*, and I would encourage every ISA to adopt some vector instruction set with similar aspects.</div><div><br></div><div>However, the more I talk with and work with my users doing SIMD programming (and my entire experience doing it personally) leads to me to believe this will be of extremely limited utility to model in the IR. There will be a small number of places where it can be used. All of those where performance matters will end up being tuned for *specific* widths anyways to get the last few % of performance. Those that aren't performance critical won't provide any substantial advantage over just being 128-bit vectorized or left scalar. At that point, we pay the complexity and maintenance cost of this completely special type in the IR for no material benefit.</div><div><br></div><div>I've said this several times in various discussions. My opinion has not changed. No new information has been presented by others or by me. So I think debating this technical point is not really interesting at this point.</div><div><br></div><div>That said, it is entirely possible that I am wrong about the utility. If the consensus in the community is that we should move forward, I'm not going to block forward progress. It sounds like Hal, the Cray folks, and many ARM folks are all positive. So far, only myself and Eric have said anything to the contrary. If there really isn't anyone else concerned with this, please just move forward. I think the cost of continuing to debate this is rapidly becoming unsustainable all on its own.</div></div></div>