search for: rl343041

On Tue, Sep 25, 2018 at 1:39 PM Sanjay Patel <spatel at rotateright.com> wrote: > I have 1 concern about adding an explicit fneg op to IR: > > Currently, fneg qualifies as a binop in IR (since there's no other way to > represent it), and we have IR transforms that are based on matching that > pattern (m_BinOp). With a proper unary fneg instruction, those transforms >

...ow we > implement the underlying fneg operation. (We have to fix those function > themselves of course to deal with the new opcode.) It's the code that > doesn't use those abstractions that has the potential to regress. > > Here's an example: > https://reviews.llvm.org/rL343041 > > The transform in question is in InstCombiner::foldShuffledBinop(). It > moves a binop ahead of a vector shuffle. It's called for every vector binop > instruction, so if IR has a unary fneg and we want that to behave as it > does today, we'd have to duplicate that fold for...