<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2015-08-17 10:05 GMT-07:00 Philip Reames <span dir="ltr"><<a href="mailto:listmail@philipreames.com" target="_blank">listmail@philipreames.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 08/16/2015 10:10 PM, David Majnemer via llvm-dev wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
With the above in mind, I don't see it as unreasonable for frontends to generate IR that LLVM is comfortable with. We seem fine telling frontend authors that they should strive to avoid large aggregate memory operations in our performance tips guide <<a href="http://llvm.org/docs/Frontend/PerformanceTips.html#avoid-loads-and-stores-of-large-aggregate-type" rel="noreferrer" target="_blank">http://llvm.org/docs/Frontend/PerformanceTips.html#avoid-loads-and-stores-of-large-aggregate-type</a>>. Implementation experience with Clang hasn't shown this to be particularly odious to follow and none of the LLVM-side solutions seem satisfactory.<br>
</blockquote></span>
David, speaking as the guy who wrote the documentation you're quoting, you're twisting the intent of that document. The document was explicitly intended to document current status, warts and all. Please do not use it to justify not fixing those warts. :)<br>
<br>
In general, I feel that a solution which worked for FCAs under some fixed size (64k, 1MB, fine!) would be better than one that worked for none. We could just document the limitation and call it a day. (I'll note that I am not endorsing or discouraging any *particular* solution to said problem.)<span class="HOEnZb"><font color="#888888"><br>
<br>
Philip<br>
</font></span></blockquote></div><br></div><div class="gmail_extra">Yes, that was pretty much my point, put in a much clearer manner. I'm also not particularly attached to this way to do it, but if this is the wrong way, then let's discuss what alternative exists and would be better rather than letting the matter stuck in limbos.<br></div></div>