
<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="">Hi Kristof,<div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Apr 27, 2017, at 9:47 AM, Kristof Beyls <<a href="mailto:kristof.beyls@arm.com" class="">kristof.beyls@arm.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">Hi Quentin,</span><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 27 Apr 2017, at 00:48, Quentin Colombet <<a href="mailto:qcolombet@apple.com" class="">qcolombet@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Hi Kristof,<div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Apr 6, 2017, at 6:53 AM, Kristof Beyls <<a href="mailto:kristof.beyls@arm.com" class="">kristof.beyls@arm.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">I've been digging a little bit deeper into the biggest performance regressions I've observed.<div class=""><br class=""></div><div class="">What I've observed so far is:</div><div class="">* A lot of the biggest regressions are caused by unnecessarily moving floating point values through general purpose registers. I've raised <a href="http://bugs.llvm.org/show_bug.cgi?id=32550" class="">http://bugs.llvm.org/show_bug.cgi?id=32550</a> for this. I think this one definitely needs fixing before enabling GlobalISel by default at -O0.</div></div></div></blockquote><div class=""><br class=""></div><div class="">I commented in the PR. This is a known problem and we have a solution. Given this is an optimization in the sense that it does not affect the correctness of the program, we didn’t push for fixing it now.</div><div class=""><br class=""></div><div class="">For O0 we wanted to focus ourselves on generating correct code. Unless the regressions you are seeing are preventing debugging/running of the program, I wouldn’t block the flip of the switch on that.</div><div class=""><br class=""></div><div class="">What do you think? </div></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">For O0, I think most users care about fast compile time and an excellent debug experience.</div><div class="">Next to that, I am told that some users also use -O0 to have a straightforward, simple, mapping between source code and the generated assembly.</div><div class=""><br class=""></div><div class="">Out of the issues I've seen so far, I think this is the single "optimization" issue that I feel gives a negative first impression of GlobalISel.</div><div class="">If users look at the generated assembly for floating point code it looks more like active de-optimization rather than "no optimization".</div><div class="">My guess is also that this may be the biggest reason for the about 20% performance slow-down and 11% code size increase I measured earlier.</div><div class="">OTOH, I clearly agree this is an optimization issue, not a correctness issue.</div><div class="">Combining the above, I think it would be best if this issue got fixed before we turn on GlobalISel by default at -O0, or we may end up hearing quite a few (non-critical) complaints about this from users.</div><div class="">Basically I think this is a tradeoff between giving a better first impression of GlobalISel vs getting more people to use and test it earlier.</div><div class=""><br class=""></div><div class="">Thanks for the write-up on the PR, that is very useful.</div><div class="">Do you have any rough idea how much effort would be involved in getting this fixed?</div></div></div></div></blockquote><div><br class=""></div><div>I’d say 2-3 weeks. Could actually be shorter if we don’t do all the refactoring I have in mind to make the table for the alternative mappings smaller, but I don’t think it is worth taking any shortcut here.</div><br class=""><blockquote type="cite" class=""><div class=""><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class=""><div class="">I got the impression Daniel is making good progress on the tablegen generation, which is key to getting this issue fixed?</div></div></div></div></blockquote><div><br class=""></div><div>To be accurate, Daniel’s work on table gen is for the select phase, not regbankselect. In other words, right now, all the table for mappings for regbankselect are hand written and Daniel’s work is not changing that. The (weak) rationale is that it is not on the critical path :).</div><br class=""><blockquote type="cite" class=""><div class=""><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class=""><div class="">I think that no matter whether we decide to switch the default before or after fixing this issue, this is one of the most urgent issues to fix as far as I can see.</div></div></div></div></blockquote><div><br class=""></div><div>Agree. This is one of the top items of my todo list.</div><br class=""><blockquote type="cite" class=""><div class=""><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class=""><div class=""><br class=""></div><div class="">If there is some way I can help contribute to fixing PR32550, I would like to help; but with the dependency on tablegen generation, I'm not sure what the best way is to help make that PR get fixed faster?</div></div></div></div></blockquote><div><br class=""></div><div>Thanks for offering to help. I agree that with the dependency on the tabelgen generation in the way, this is probably not a good use of your time. Depending when I can spare some time on this, I’ll either do it or explain the refactoring in the google doc.</div><div><br class=""></div><div>In the meantime, I’d suggest to focus on validating the debug info on your side.</div><br class=""><blockquote type="cite" class=""><div class=""><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class=""><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><div class=""><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="">* FastISel seems to transform division-by-constant-power-of-2 into right shift (see <a href="https://github.com/llvm-mirror/llvm/blob/master/lib/CodeGen/SelectionDAG/FastISel.cpp#L456-L468" class="">https://github.com/llvm-mirror/llvm/blob/master/lib/CodeGen/SelectionDAG/FastISel.cpp#L456-L468</a>). GlobalISel does not. It seems to me that at -O0 there may be reasons not perform this transformation, but maybe there is a good reason why FastISel does this?</div></div></div></blockquote><div class=""><br class=""></div><div class="">I think FastISel tries to generate the best code it can no matter what. For GISel O0 however, not doing this optimization sounds sensible to me.</div><div class="">Now, I would say that the same remark as the previous bullet point apply: we shouldn’t do it unless it gets in the way of running/debugging the program.</div></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">I agree that these optimizations should not be done at -O0. I think not doing them is actually an improvement: you give the user what they asked, i.e. "no optimization", and an as-straigthforward-as-possible mapping from source to assembly.</div><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><div class=""><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="">* FastISel doesn’t\ seem to handle functions with switch statements, so it falls back to DAGISel. DAGISel produces code that's a lot better than GlobalISel for switch statement at -O0. I'm not sure if we need to do something here before enabling GlobalISel by default. I'm thinking we may need to add a smarter way to lower switch statements rather than just a cascaded sequence of conditional branches.</div></div></div></blockquote><div class=""><br class=""></div><div class="">Sounds optimization-ish to me. Same remark.</div></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">Agreed, optimization-ish. In comparison to the above point on FastISel "peepholes", I think that lowering switch statements to something else than a cascaded sequence of conditional branches doesn't make the generated code harder to map to the source. So, in comparison to the above point on FastISel "peepholes", I'm not actively against being smarter about lowering switch statements at -O0.</div><div class="">But I agree, this shouldn't hold up turning on GlobalISel by default at -O0.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Other than the above remarks, before turning on GlobalISel by default, we'd better test/verify that debug info quality remains good.</div><div class="">I haven't looked into that at all, but am hoping to start looking into that soon, with the help of the DIVA tool (<a href="https://github.com/SNSystems/DIVA" class="">https://github.com/SNSystems/DIVA</a>) presented at last EuroLLVM (<a href="http://llvm.org/devmtg/2017-03//assets/slides/diva_debug_information_visual_analyzer.pdf" class="">http://llvm.org/devmtg/2017-03//assets/slides/diva_debug_information_visual_analyzer.pdf</a>). I don't recall anyone so far making any statements about the quality of the debug info they've measured or experienced with GlobalISel enabled?</div></div></div></div></blockquote><div><br class=""></div><div>We ran the lldb test suite with GISel. IIRC, Tim has the details, GISel was on part with SDISel.</div><br class=""><blockquote type="cite" class=""><div class=""><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class=""><div class=""><br class=""></div><div class="">Other than the all of the above, I just wanted to mention that Oliver recently started running csmith on AArch64 GlobalISel and found one issue so far that already got fixed (<a href="https://bugs.llvm.org//show_bug.cgi?id=32733" class="">https://bugs.llvm.org//show_bug.cgi?id=32733</a>).</div><div class="">If he finds other correctness issues, I'm sure he'll keep on reporting them.</div></div></div></div></blockquote><div><br class=""></div>Great!</div><div><br class=""></div><div>Thanks,</div><div>-Quentin<br class=""><blockquote type="cite" class=""><div class=""><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><div class=""><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="">I'll try to add the above content to the document Diana created at <font color="#1155cc" face="arial, sans-serif" class=""><span class="" style="font-size: 12.8px; orphans: 2; widows: 2; background-color: rgb(255, 255, 255);"><a href="https://goo.gl/IS2Bdw" class="">https://goo.gl/IS2Bdw</a></span></font> too.</div><div class=""><br class=""></div><div class="">Thanks,</div><div class=""><br class=""></div><div class="">Kristof</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 3 Apr 2017, at 17:10, Kristof Beyls <<a href="mailto:Kristof.Beyls@arm.com" class="">Kristof.Beyls@arm.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">I've kicked off a run to compare "-O0 -g" versus "-O0 -g -mllvm -global-isel -mllvm -global-isel-abort=2".<div class="">I've selected the test-suite (albeit a version which is a couple of months old now) and a few short-running proprietary benchmarks to get data back quickly for an initial feel of where things are.</div><div class="">This was running on Cortex-A57 AArch64 Linux.</div><div class=""><br class=""></div><div class="">I saw one assertion failure in GlobalISel, see <a href="http://bugs.llvm.org/show_bug.cgi?id=32471" class="">http://bugs.llvm.org/show_bug.cgi?id=32471</a>. This is in a program compiled at -O2 (my out-dated test-suite still overrides -O0 and instead uses -O for that program). The root cause of the failure seems to be due to LowLevelType not supporting vectors of pointers. I think this demonstrates that for correctness, we should be trying to test more than -O0, or even more than just LLVM-IR produced by clang, as other front-ends could run into this even at -O0.</div><div class=""><br class=""></div><div class="">Due to this assertion failure and the infrastructure I used, the numbers below do not include test-suite/MultiSource/Benchmarks results.</div><div class=""><br class=""></div><div class="">On the non-correctness aspects, LNT tells me that:</div><div class="">- The programs that report execution time, on geomean are about 17% slower.</div><div class="">- The programs that report scores, on geomean are about 21% slower.</div><div class="">- Code size is up on geomean about 11%.</div><div class="">I'm afraid I don't have compile time numbers, nor any feel for debug info quality.</div><div class=""><br class=""></div><div class="">I'll need quite a bit more time to dig into the details to come up with something actionable, although the fact that LowLevelType doesn't support vectors of pointers is already actionable.</div><div class="">Nevertheless, I thought to share what I see as is, to see if others see similar results so far.</div><div class=""><br class=""></div><div class="">I thought Diana was going to look into fallback rate on the test-suite on AArch64 linux?</div><div class=""><br class=""></div><div class="">Thanks,</div><div class=""><br class=""></div><div class="">Kristof</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class="">On 30 Mar 2017, at 10:54, Renato Golin <<a href="mailto:renato.golin@linaro.org" class="">renato.golin@linaro.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">On 30 March 2017 at 00:27, Quentin Colombet <<a href="mailto:qcolombet@apple.com" class="">qcolombet@apple.com</a>> wrote:<br class=""><blockquote type="cite" class="">On iOS we are at 100% pass rate in 00 g for the LLVM test suite, standard<br class="">benchmarks and unit tests. In about 5% of all functions GlobalIsel falls<br class="">back to SDIsel.<br class="">(Kristof Beyls would have the linux numbers.)<br class="">The self host compiler correctly builds and runs the LLVM test suite in O0.<br class=""></blockquote><br class="">Having done no tests at all on my side, I think we need to have<br class="">similar numbers on Linux to be able to flip across the board.<br class=""><br class="">I don't want to flip it only for Darwin and not Linux, as that will<br class="">fragment the effort too much.<br class=""><br class="">I'll check with Diana and Kristof to know what's the best way forward,<br class="">but it should be reasonably quick.<br class=""><br class="">cheers,<br class="">--renato</div></blockquote></div></div></div></blockquote></div></div></div></div></blockquote></div></div></div></div></blockquote></div></div></div></blockquote></div><br class=""></div></body></html>