[PATCH] D15857: [InstCombine] Defend against worst-case exponential execution time

[David Majnemer via llvm-commits]

On Tue, Jan 5, 2016 at 1:15 AM, James Molloy <james at jamesmolloy.co.uk>
wrote:

> Hi David,
>
> > Out of curiosity, is there a major benefit to canonicalizing this in
> the middle-end vs doing this transform in code-gen prepare?
>
> Major? no. My initial implementation was to do this in ISelLowering, but
> it was remarked that matching bitreversals is a fairly generic concept that
> other backends could benefit from.
>
> The code already in instcombine (since at least 2010) to match bswaps
> performs almost exactly the same steps as matching bitreversals (apart from
> it looks at bytes rather than bits). I therefore thought the most obvious
> thing to do would be to tweak the existing algorithm and improve it.
>
> Do you think it's too heavyweight for instcombine?
>

I think it might be too heavyweight and I haven't seen an argument for why
it's valuable to canonicalize upfront.  bswap is a little more reasonable
because there are fewer "parts" and we want to eliminate bswap pairs.


>
> James
>
> On Mon, 4 Jan 2016 at 23:13 David Majnemer via llvm-commits <
> llvm-commits at lists.llvm.org> wrote:
>
>> majnemer added a comment.
>>
>> Out of curiosity, is there a major benefit to canonicalizing this in the
>> middle-end vs doing this transform in code-gen prepare?
>>
>>
>> Repository:
>>   rL LLVM
>>
>> http://reviews.llvm.org/D15857
>>
>>
>>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160105/4071d13c/attachment-0001.html>