<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jul 7, 2016, at 4:24 PM, Eli Friedman <<a href="mailto:eli.friedman@gmail.com" class="">eli.friedman@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">On Thu, Jul 7, 2016 at 10:39 AM, Quentin Colombet<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:qcolombet@apple.com" target="_blank" class="">qcolombet@apple.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style="word-wrap: break-word;" class=""><div class="">Hi Eli,</div><div class=""><br class=""></div><div class="">Thanks for your feedbacks.</div><div class=""><br class=""></div><div class="">Answers inlined.</div><br class=""><div class=""><span class=""><blockquote type="cite" class=""><div class="">On Jun 22, 2016, at 4:21 PM, Eli Friedman <<a href="mailto:eli.friedman@gmail.com" target="_blank" class="">eli.friedman@gmail.com</a>> wrote:</div><br class=""><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;" class=""><div class="gmail_extra">On Wed, Jun 22, 2016 at 2:39 PM, Tim Northover<span class=""> </span><span dir="ltr" class=""><<a href="mailto:t.p.northover@gmail.com" target="_blank" class="">t.p.northover@gmail.com</a>></span><span class=""> </span>wrote:<br class=""><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><span class="">> I'm not sure if this is really going to work the way you want. On x86 with<br class="">> AVX (but not AVX2), is LOAD <8 x i32> legal? I mean, you could declare that<br class="">> it is... but you're going to end up with a bunch of vector shuffles trying<br class="">> to legalize ADD <8 x i32>. You could clean it up afterwards with some sort<br class="">> of optimization pass to split vectors where it's profitable... but it gets<br class="">> complicated when you start dealing with values with multiple uses and PHI<br class="">> nodes.<br class=""><br class=""></span>This still seems to be something for RegBankSelect to me. It's going<br class="">to see something like<br class=""><br class=""> <span class=""> </span>%0(256) = G_LOAD <4 x i32> ...<br class=""> <span class=""> </span>%1(128) = G_EXTRACT <2 x i32> %0, 0<br class=""> <span class=""> </span>%2(128) = G_EXTRACT <2 x i32> %0, 1<br class=""> <span class=""> </span>%3(128) = G_ADD <2 x i32> %1, ...<br class=""> <span class=""> </span>%4(128) = G_ADD <2 x i32> %2, ...<br class=""> <span class=""> </span>%5(256) = G_SEQ <4 x i32> %3 %4<br class=""><br class="">and ought to have the cost model necessary to decide that (XMM, XMM)<br class="">is the best register class (in whatever representation it has, an<br class="">extension of the .td RegClasses with tuples) rather than YMM.<br class=""></blockquote><br class="">We run RegBankSelect after legalization? Then what happens? Presumably, if you have a load or arithmetic operation whose result ends up in (XMM, XMM), you then want to split it so you have two operations which each end up in one xmm register... then you have a bunch of new operations which haven't been through legalization and register bank selection, so you need to run legalization and RegBankSelect from the top again?<span class="Apple-converted-space"> </span></div></div></div></div></blockquote><div class=""><br class=""></div></span><div class="">No, we do not run the full legalizer. RegBankSelect creates very specific operations (glorified copies per say, this includes extract and build_sequence) and the plan is to apply the legalizer helper on them.</div></div></div></blockquote><div class=""><br class=""></div><div class="">That works to split a vector... not so much to split an integer. </div></div></div></div></div></blockquote><div><br class=""></div><div>Ok, let me clarify, I think I see the misunderstanding.</div><div>The generic code of RegBankSelect will only insert glorified version of copies.</div><div>The target specific code can do whatever it wants like splitting add and such. The caveat is that whatever the target does, it needs to be able to select it, so it must be legal (even if the target runs the legalizer helper when doing the remapping).</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">For example, to split an i64 add, you end up with adde operations... which probably aren't legal. Not sure if that will come up in practice.<br class=""></div><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style="word-wrap: break-word;" class=""><div class=""><span class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;" class=""><div class="gmail_extra"><div class="gmail_quote">Or do we have some sort of restricted post-RegBankSelect legalizer which doesn't require a second pass?<br class=""></div></div></div></div></blockquote><div class=""><br class=""></div></span>No, see my previous answer.</div><div class=""><span class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;" class=""><div class="gmail_extra"><div class="gmail_quote"><br class="">If we're doing custom lowering before RegBankSelect, we could end up being effectively forced to choose a bank during legalization, without the benefit of a cost model.<span class="Apple-converted-space"> </span></div></div></div></div></blockquote><div class=""><br class=""></div></span><div class="">Even custom lowered instructions can be remapped. The target can specify alternative instructions mapping for every instruction, generic or not.</div></div></div></blockquote><div class=""><br class=""></div><div class="">I assume by "remapped" you mean there's a target hook to transform the instruction (tables probably aren't enough in some cases). And I guess it would be a requirement that all operations generated at this point are legal? </div></div></div></div></div></blockquote><div><br class=""></div><div>That is correct.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""> That can be kind of awkward in some cases.<br class=""></div></div></div></div></div></blockquote><div><br class=""></div><div>How so? (I guess your later example try to convey that, but I did not get the problem)</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style="word-wrap: break-word;" class=""><div class=""><span class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;" class=""><div class="gmail_extra"><div class="gmail_quote">For example, if you need to custom-lower an <8 x i32> shuffle on AVX, the result could look substantially different depending on whether the result needs to be in on YMM or two XMM registers. Things become even more awkward if you don't distinguish between integer and vector registers on x86; for example, if I have an i64 add on x86-32, does it need to be widened to <2 x i64> or split into two i32 ADDE operations?<br class=""></div></div></div></div></blockquote><div class=""><br class=""></div></span><div class="">I don’t understand the example. Also how is this different from what we currently do?</div></div></div></blockquote><div class=""><br class=""></div><div class="">For the<span class="Apple-converted-space"> </span><span class=""><8 x i32><span class="Apple-converted-space"> </span></span>shuffle example, you have an illegal shuffle; legalization splits it into multiple shuffles (this would happen before RegBankSelect, right?). RegBankSelect sees the shuffles, and considers splitting them... but how does it figure out how many shuffles you end up with?</div></div></div></div></div></blockquote><div><br class=""></div><div>That’s up to the target. It will say it maps the <8 x i32> on N definition and materialize that target.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""> One way is to merge the shuffles, but that involves RegBankSelect special-casing shuffles. </div></div></div></div></div></blockquote><div><br class=""></div><div>Yeah, merging is not something I wanted to consider in RegBankSelect, at least for now.</div><div>One thing to keep in mind is that unlike SDISel, you can insert new target specific (or target independent) passes wherever you want in the pipeline. Therefore if we need a shuffle combiner of some sort, we do not have to do it in regbankselect or legalization.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">And we don't really want to end up with a bunch of special cases in RegBankSelect. IIRC, this is an existing problem with SDISel to some extent because we consider <8 x i32> legal, so it's not really something new, but it's worth considering.<br class=""><br class=""></div><div class="">A different example: suppose you have an `add <1 x i64>` and an `add i64` on x86-32. (`<1 x i64>` comes up with code ported from MMX.) Currently, ISel will put the former into a vector register, and the latter into integer registers. (This isn't ideal, but it generally works out reasonably well.) With GlobalISel, both are just an i64 add, and i64 isn't legal, so we have to decide: do we WidenVector or NarrowScalar? Without any context, there isn't an obvious right answer. </div></div></div></div></div></blockquote><div><br class=""></div><div>The options I see are:</div><div>- Mark it legal, you know how to select it and let the regbankselect decide. I actually don’t get why it is illegal in your example.</div><div>- Mark it custom and look for context around.</div><div><br class=""></div><div>I would recommend the first approach.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">We have a few options:<br class=""><br class="">1. always WidenVector, and end up with terrible code if we need to transfer the result to integer registers;<br class="">2. always NarrowScalar, and end up with terrible code if we need to transfer the result to xmm registers;<span class="Apple-converted-space"> </span><br class="">3. pretend i64 add is legal, and let RegBankSelect assign it to either a fake vector register or a fake integer register<br class=""></div></div></div></div></div></blockquote><div><br class=""></div><div>Why pretend, this is legal, right?</div><div><br class=""></div><div>To me legal means we know how to select it and with that definition add i64 seems legal to me.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">4. "cheat", and use the IR type as an input to legalization<br class=""></div><div class="">5. add a bunch of code separate from legalization and RegBankSelect to try and handle this. (For example, x86 could have a special pass before legalization which does some sort of cost analysis, then uses legalization helpers to force legalization to happen in a specific manner.)<br class=""></div></div><br class=""></div><div class="gmail_extra">-Eli</div></div></div></blockquote></div><br class=""></body></html>