Re: Don't use integer "FMA" for shifts

2019-08-06 Thread Richard Sandiford
"Richard Earnshaw (lists)" writes: > On 30/07/2019 11:50, Richard Sandiford wrote: >> Richard Biener writes: >>> On Tue, Jul 30, 2019 at 12:04 PM Richard Sandiford >>> wrote: tree-ssa-math-opts supports FMA optabs for integers as well as floating-point types, even though there's n

Re: Don't use integer "FMA" for shifts

2019-07-30 Thread Richard Earnshaw (lists)
On 30/07/2019 11:50, Richard Sandiford wrote: Richard Biener writes: On Tue, Jul 30, 2019 at 12:04 PM Richard Sandiford wrote: tree-ssa-math-opts supports FMA optabs for integers as well as floating-point types, even though there's no distinction between fused and unfused there. It turns

Re: Don't use integer "FMA" for shifts

2019-07-30 Thread Richard Biener
On Tue, Jul 30, 2019 at 12:50 PM Richard Sandiford wrote: > > Richard Biener writes: > > On Tue, Jul 30, 2019 at 12:04 PM Richard Sandiford > > wrote: > >> > >> tree-ssa-math-opts supports FMA optabs for integers as well as > >> floating-point types, even though there's no distinction between >

Re: Don't use integer "FMA" for shifts

2019-07-30 Thread Richard Sandiford
Richard Biener writes: > On Tue, Jul 30, 2019 at 12:04 PM Richard Sandiford > wrote: >> >> tree-ssa-math-opts supports FMA optabs for integers as well as >> floating-point types, even though there's no distinction between >> fused and unfused there. It turns out to be pretty handy for the >> IFN

Re: Don't use integer "FMA" for shifts

2019-07-30 Thread Richard Biener
On Tue, Jul 30, 2019 at 12:04 PM Richard Sandiford wrote: > > tree-ssa-math-opts supports FMA optabs for integers as well as > floating-point types, even though there's no distinction between > fused and unfused there. It turns out to be pretty handy for the > IFN_COND_* handling though, so I don

Don't use integer "FMA" for shifts

2019-07-30 Thread Richard Sandiford
tree-ssa-math-opts supports FMA optabs for integers as well as floating-point types, even though there's no distinction between fused and unfused there. It turns out to be pretty handy for the IFN_COND_* handling though, so I don't want to remove it, however weird it might seem. Instead this patc