<p dir="ltr">I'm pretty sure volatile access voids your performance warranty....</p>
<p dir="ltr">I assume the issue is that the loads and stores aren't combined late in the back end because we propagate the volatile? I think the fix for performance is "don't use volatile". I'm sure you've looked at that option, but we'll need a lot more context on what problem you're actually hitting to provide more realistic options.</p>
<p dir="ltr">I think TTI is a very bad fit here -- target customization would really hurt the entire canonicalization efforts of the middle end....</p>
<br><div class="gmail_quote"><div dir="ltr">On Wed, Nov 11, 2015, 10:34 Krzysztof Parzyszek via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 11/11/2015 9:28 AM, Chandler Carruth wrote:<br>
> So, here is the model that LLVM is using: a volatile memcpy is lowered<br>
> to a loop of loads and stores of indeterminate width. As such, splitting<br>
> a memcpy is always valid.<br>
><br>
> If we want a very specific load and store width for volatile accesses, I<br>
> think that the frontend should generate concrete loads and stores of a<br>
> type with that width. Ultimately, memcpy is a pretty bad model for<br>
> *specific* width accesses, it is best at handling indeterminate sized<br>
> accesses, which is exactly what doesn't make sense for device backed<br>
> volatile accesses.<br>
><br>
<br>
Yeah, the remark about devices I made in my post was a result of a<br>
"last-minute" thought to add some rationale.  It doesn't actually apply<br>
to SROA, since there are no devices that are mapped to the stack, which<br>
is what SROA is interested in.<br>
<br>
The concern with the testcase I attached is really about performance.<br>
Would it be reasonable to control the splitting in SROA via TTI?<br>
<br>
-Krzysztof<br>
<br>
--<br>
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,<br>
hosted by The Linux Foundation<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>