[PATCH] D12139: Add 'strlen' formation to LoopIdiomRecognize

[Nick Lewycky via llvm-commits]

On 20 August 2015 at 13:31, Alex Rosenberg <alexr at leftfield.org> wrote:

> alexr added a subscriber: alexr.
> alexr added a comment.
>
> 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.
>
> 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.
>
> 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.
>

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.

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.

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?

Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150824/6758badb/attachment.html>