search for: foldshuffledbinop

...ix 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 fneg (or fake it by > substituting an fsub). > > But after rumma...

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 >

On Wed, Sep 26, 2018 at 9:32 AM Sanjay Patel <spatel at rotateright.com> wrote: > > > On Tue, Sep 25, 2018 at 7:47 PM Cameron McInally <cameron.mcinally at nyu.edu> > wrote: > >> >> This is the first time I'm looking at foldShuffledBinop(...), so maybe a >> naive question, but why not do similar shuffle canonicalizations on unary >> (or ternary) operations? That may be a better fix in the long run. >> > > AFAIK, all of the math/logic folding that we do currently is on binary > operators because all of the...