search for: optimizeselectinst

Changing the order of the checks in CodeGenPrepare::optimizeSelectInst() sounds good to me. But you may need to go further for optimum performance. For example, we may be canonicalizing math/logic IR patterns into 'select' such as in the recent: https://reviews.llvm.org/D67799 So if you want those to become ALU ops again rather than branches, then you need t...

On Sun, Sep 29, 2019 at 3:35 PM Joan Lluch via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi Sanjay, > > Actually, the CodeGenPrepare::optimizeSelectInst is not doing the best it could do in some circumstances: The case of “OptSize" for targets not supporting Select was already mentioned to be detrimental. > > For targets that actually have selects, but branches are cheap and generally profitable, particularly for expensive operators, the...

...clear now. > > John. > > > On 29 Sep 2019, at 15:57, Roman Lebedev <lebedev.ri at gmail.com> wrote: > > On Sun, Sep 29, 2019 at 3:35 PM Joan Lluch via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > > Hi Sanjay, > > Actually, the CodeGenPrepare::optimizeSelectInst is not doing the best it could do in some circumstances: The case of “OptSize" for targets not supporting Select was already mentioned to be detrimental. > > For targets that actually have selects, but branches are cheap and generally profitable, particularly for expensive operators, the...

...clear now. > > John. > > > On 29 Sep 2019, at 15:57, Roman Lebedev <lebedev.ri at gmail.com> wrote: > > On Sun, Sep 29, 2019 at 3:35 PM Joan Lluch via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > > Hi Sanjay, > > Actually, the CodeGenPrepare::optimizeSelectInst is not doing the best it > could do in some circumstances: The case of “OptSize" for targets not > supporting Select was already mentioned to be detrimental. > > For targets that actually have selects, but branches are cheap and > generally profitable, particularly for expensive...

...gt; wrote: >>> >>> On Sun, Sep 29, 2019 at 3:35 PM Joan Lluch via llvm-dev >>> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >>> >>> >>> Hi Sanjay, >>> >>> Actually, the CodeGenPrepare::optimizeSelectInst is not doing the best it could do in some circumstances: The case of “OptSize" for targets not supporting Select was already mentioned to be detrimental. >>> >>> For targets that actually have selects, but branches are cheap and generally profitable, particularly for expensi...

I agree with John; also, if you decide to go this route, you can reuse the code from CodeGenPrepare::optimizeSelectInst: https://github.com/llvm/llvm-project/blob/master/llvm/lib/CodeGen/CodeGenPrepare.cpp#L6065 Alexey On Thu, Jan 30, 2020 at 9:00 PM John Regehr via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Several different passes introduce select instructions, such as > InstCombine, SimplifyC...

I run "clang ... --emit-llvm ....". I get LLVM IR select instructions out. I don't want select instructions, but want explicit control flow. Is there a way to do this? I'm scared of disabling the SimplifyCFG pass since it appears to do much more than just rewrite to use select statements. -------------- next part -------------- An HTML attachment was scrubbed... URL:

...;>>> On Sun, Sep 29, 2019 at 3:35 PM Joan Lluch via llvm-dev >>>> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >>>> >>>> >>>> Hi Sanjay, >>>> >>>> Actually, the CodeGenPrepare::optimizeSelectInst is not doing the best it could do in some circumstances: The case of “OptSize" for targets not supporting Select was already mentioned to be detrimental. >>>> >>>> For targets that actually have selects, but branches are cheap and generally profitable, particularly for...

Hi, I would like to know if there's a way to avoid select instructions during the IR generation. What are the optimization passes that can result in a select instruction? i.e. I want to preserve branches in my code without disabling any other optimizations applicable. For example, void foo(int* x, int* y){ if(*x > 0){ *y = *x + 10; } else{ *y = *x + 20; } }