<div dir="ltr"><div><div><div>OK, what about that plan :<br><br></div>Slice the aggregate into a serie of valid loads/stores for non atomic ones.<br></div>Use big scalar for atomic/volatile ones.<br></div>Try to generate memcpy or memmove when possible ?<br><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-08-17 12:16 GMT-07:00 deadal nix <span dir="ltr"><<a href="mailto:deadalnix@gmail.com" target="_blank">deadalnix@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">2015-08-17 11:26 GMT-07:00 Mehdi Amini <span dir="ltr"><<a href="mailto:mehdi.amini@apple.com" target="_blank">mehdi.amini@apple.com</a>></span>:<br><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,<div><br><div><span><blockquote type="cite"><div>On Aug 17, 2015, at 12:13 AM, deadal nix via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:</div><br><div><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2015-08-16 23:21 GMT-07:00 David Majnemer <span dir="ltr"><<a href="mailto:david.majnemer@gmail.com" target="_blank">david.majnemer@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span></span><div>Because a solution which doesn't generalize is not a very powerful solution. What happens when somebody says that they want to use atomics + large aggregate loads and stores? Give them yet another, different answer? That would mean our earlier, less general answer, approach was either a bandaid (bad) or the new answer requires a parallel code path in their frontend (worse).</div></div></div></div></blockquote></div></div></div></div></blockquote><div><br></div><div><br></div></span><div>+1 with David’s approach: making thing incrementally better is fine *as long as* the long term direction is identified. Small incremental changes that makes things slightly better in the short term but drives us away of the long term direction is not good.</div><div><br></div><div>Don’t get me wrong, I’m not saying that the current patch is not good, just that it does not seem clear to me that the long term direction has been identified, which explain why some can be nervous about adding stuff prematurely. </div><div>And I’m not for the status quo, while I can’t judge it definitively myself, I even bugged David last month to look at this revision and try to identify what is really the long term direction and how to make your (and other) frontends’ life easier. </div><span><div><br></div><div><br></div></span></div></div></div></blockquote><div><br></div></span><div>As long as there is something to be done. Concern has been raised for very large aggregate (64K, 1Mb) but there is no way a good codegen can come out of these anyway. I don't know of any machine that have 1Mb of register available to tank the load. Even I we had a good way to handle it in InstCombine, the backend would have no capability to generate something nice for it anyway. Most aggregates are small and there is no good excuse to not do anything to handle them because someone could generate gigantic ones that won't map nicely to the hardware anyway.<br><br></div><div>By that logic, SROA should not exists as one could generate gigantic aggregate as well (in fact, SROA fail pretty badly on large aggregates).<br><br></div><div>The second concern raised is for atomic/volatile, which needs to be handled by the optimizer differently anyway, so is mostly irrelevant here.<br></div></div><span class=""><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><span><blockquote type="cite"><div><div dir="ltr"><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 dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><div> </div></span></div></div></div></blockquote><br></div><br></div><div class="gmail_extra">clang has many developer behind it, some of them paid to work on it. That s simply not the case for many others.<br><br></div><div class="gmail_extra">But to answer your questions :<br></div><div class="gmail_extra"> - Per field load/store generate more loads/stores than necessary in many cases. These can't be aggregated back because of padding.<br></div><div class="gmail_extra"> - memcpy only work memory to memory. It is certainly usable in some cases, but certainly do not cover all uses.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">I'm willing to do the memcpy optimization in InstCombine (in fact, things would not degenerate into so much bikescheding, that would already be done).<br></div></div></div></blockquote><div><br></div></span></div></div><div>Calling out “bikescheding” what other devs think is what keeps the quality of the project high is unlikely to help your patch go through, it’s probably quite the opposite actually.</div><div><br></div><div><br></div></div></blockquote><br></div></span>I understand the desire to keep quality high. That's is not where the problem is. The problem lies into discussing actual proposal against hypothetical perfect ones that do not exists.<br></div><div class="gmail_extra"><br></div></div>
</blockquote></div><br></div>