<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 20 August 2015 at 13:31, Alex Rosenberg <span dir="ltr"><<a href="mailto:alexr@leftfield.org" target="_blank">alexr@leftfield.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">alexr added a subscriber: alexr.<br>
alexr added a comment.<br>
<br>
This makes me very nervous. We have fielded a lot of user complaints about canonicalizing loops into memcpy calls. strlen feels like a more dubious choice.<br>
<br>
My past experience writing SIMD versions of string functions tells me that the typical string length that strlen is tuned for may be very different from the amount of data an open-coded loop is intended to handle.<br>
<br>
I would want to see very tuned lowering code to go with this. I'd also very much like to see the lowering code pay attention to target-specific cost information such as the possible cost to cross a dynamic library boundary when weighing the lowering of a call vs expanding inline.<br></blockquote><div><br></div><div>Yes, I share your concerns. We do vectorize an open-coded strlen loop, for instance. SCEV will also convert it into a constant if it runs over constant data.</div><div><br></div><div>The purpose behind this patch is to allow other strlen()-specific optimizations to fire. The particular case I have is one where strlen(x?"foo":"bars") folds to x?3:4.<br></div><div><br></div><div><div>I am not going to do the lowering code myself, or at least not within the foreseeable future. Are you okay with this patch going in and you disabling it, or do you want me to drop the patch, or wait for someone else to volunteer to work on the backend lowering?</div></div><div><br></div><div>Nick</div><div><br></div></div></div></div>