[llvm-dev] Rotates, once again

[Sanjay Patel via llvm-dev]

A rotate intrinsic should be relatively close in cost/complexity to the
existing bswap.

A grep of intrinsic::bswap says we'd probably add code in:
InstCombine
InstructionSimplify
ConstantFolding
DemandedBits
ValueTracking
VectorUtils
SelectionDAGBuilder

But I don't think it's fair to view those additions as pure added cost. As
an example, consider that we have to add hacks to EarlyCSE to recognize
multi-IR-instruction min/max/abs patterns. Intrinsics just work as-is
there. So if you search for 'matchSelectPattern', you get an idea (I see 32
hits in 10 files) of the cost of *not* having intrinsics for those
operations that we've decided are not worthy of intrinsics.


On Wed, May 16, 2018 at 2:20 PM, John Regehr via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> On 5/16/18 1:58 PM, Sanjay Patel via llvm-dev wrote:
>
> An informal metric might be: if the operation is supported as a primitive
>> op or built-in in source languages and it is supported as a single target
>> instruction, can we guarantee that 1-to-1 translation through optimization?
>>
>
> It seems perfectly reasonable for LLVM users to expect this to happen
> reliably.
>
> I'd like to take a look at the other side of the equation: the cost of
> adding a new intrinsic in terms of teaching passes to see through it, so we
> don't lose optimizations that worked before the intrinsic was added.
>
> For example, clearly ValueTracking needs a few lines added so that
> computeKnownBits and friends don't get stopped by a rotate. Anyone have a
> reasonably complete list of files that need similar changes?
>
> John
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180517/ab4ec4a6/attachment.html>