<div dir="ltr">On Wed, Jun 22, 2016 at 1:16 PM, Quentin Colombet <span dir="ltr"><<a href="mailto:qcolombet@apple.com" target="_blank">qcolombet@apple.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Hi Tim,<div><br><div><span><blockquote type="cite"><div>On Jun 22, 2016, at 9:16 AM, Tim Northover <<a href="mailto:t.p.northover@gmail.com" target="_blank">t.p.northover@gmail.com</a>> wrote:</div><br><div><div>Hi Quentin,<br><br>On 21 June 2016 at 11:58, Quentin Colombet <<a href="mailto:qcolombet@apple.com" target="_blank">qcolombet@apple.com</a>> wrote:<br><blockquote type="cite">I believe this is work in progress so I did not go into great details to comment on each part of the patch. For instance, for a detailed review, I would have expected the patch to be split into smaller one.<br></blockquote><br>Sure, I'll try to look for smaller independently testable bits.<br><br><blockquote type="cite">- I would split the file with the legalization APIs in two:<br>  - one for the machine pass<br>  - one for the helper<br><br>The rationale is to be able to include them independently.<br><br>- I would split the LegalizeHelper in two:<br>  - One with all the methods you added (narrow, widen, etc), but legalize<br>  - One with the legalize API and the set action stuff<br></blockquote><br>Yep, sounds compeltely reasonable.<br><br><blockquote type="cite">- Replace the Type/EVT by something lower level (Cf. my email)<br><br>Basically, we do not need to know what are the types, we only need to know their size and there number of lanes, i.e., I would go with a different types representation for the MI level.<br></blockquote><br>I think we do need to know the the full types (at least MVT<br>information) to decide on the correct action. <4 x float> could have<br>very different requirements from <4 x i32>. I'm afraid I'm not sure<br>what e-mail you're talking about either, do you have a link handy?<br></div></div></blockquote><div><br></div></span><div>I was talking of the offline discussion in "<span style="color:rgba(0,0,0,0.498039);font-family:'Helvetica Neue';font-size:15px">GISel - reality check"</span></div><div><br></div><div>That’s just a remark in that email, the basic idea is what I said, I.e., I think we only need the size and number of lanes.</div><div>Let me explain a bit why I think it is sufficient.</div><div><4 x float> and <4 x i32> are <4 x 32-bit> for most operations (load, store, and, shuffle, etc.). The only cases where that make a difference AFAICT are arithmetic operations. However, for those, the type is actually encoded in the opcode, e.g., fadd vs. add (we do not have G_FADD yet but I think we should :)). In other word, when type matters, the opcode should give us the information otherwise we should be able to get away of that business.</div><div><br></div></div></div></div></blockquote><div><br></div><div>I'm not sure if this is really going to work the way you want. On x86 with AVX (but not AVX2), is LOAD <8 x i32> legal?  I mean, you could declare that it is... but you're going to end up with a bunch of vector shuffles trying to legalize ADD <8 x i32>. You could clean it up afterwards with some sort of optimization pass to split vectors where it's profitable... but it gets complicated when you start dealing with values with multiple uses and PHI nodes.<br><br></div><div>Whether it makes sense to distinguish <1 x i64> vs. i64 is a similar sort of issue.<br></div><div><br></div><div>-Eli<br></div></div></div></div>