search for: pr31274

...simpler if we had a > rotate > intrinsic, and the 6-to-1 margin is the biggest I've seen. Given that this is a general problem that occurs with other instruction sequences as well, wouldn't it make more sense to make the cost model handle more than one instruction, as suggested in PR31274 [1]? [1] https://bugs.llvm.org/show_bug.cgi?id=31274 In all these cases (rotate, min, max, abs, fma, add-with-overflow, and probably many more) there's a tradeoff between elaborating them as simpler IR instructions and modelling them as its own instruction / intrinsic. A big disadvantage...

...te >> intrinsic, and the 6-to-1 margin is the biggest I've seen. >> > > Given that this is a general problem that occurs with other instruction > sequences as well, wouldn't it make more sense to make the cost model > handle more than one instruction, as suggested in PR31274 [1]? > > [1] https://bugs.llvm.org/show_bug.cgi?id=31274 > > Yes, I think everyone agrees that we need to improve the cost model interface. Note that there's a proposal for review for the 1 IR -> many machine ops variant of this question: https://reviews.llvm.org/D46276 > I...

Thanks for writing this up. I'd like to have this intrinsic too. Another argument for having the intrinsic is shown in PR37426: https://bugs.llvm.org/show_bug.cgi?id=37426 Vectorization goes overboard because the throughput cost model used by the vectorizers doesn't match the 6 IR instructions that correspond to 1 x86 rotate instruction. Instead, we have: $ opt 37426prevectorize.ll -S

Hi everyone! I recently ran into some interesting issues with generation of rotate instructions - the details are in the bug tracker (https://bugs.llvm.org/show_bug.cgi?id=37387 and related bugs) for those interested - and it brought up the issue of rotates in the IR again. Now this is a proposal that has been made (and been rejected) several times, but I've been told that this time round we