On Tue, Aug 13, 2019 at 9:54 PM H.J. Lu <hjl.to...@gmail.com> wrote: > > > with the latest patch (this is with -m32) where -mstv causes > > > all spills to go away and the cmoves replaced (so clearly > > > better code after the patch) for pr65105-5.c, no obvious > > > improvements for pr65105-3.c where cmov does appear with -mstv. > > > I'd rather not "fix" those by adding -mno-stv but instead have > > > the Intel people fix costing for slm and/or decide what to do. > > > For pr65105-3.c I'm not sure why if-conversion didn't choose > > > to use cmov, so clearly the enabled minmax patterns expose the > > > "failure" here. > > I'm not sure how much effort Intel is putting into Silvermont tuning > > these days. So I'd suggest giving HJ a heads-up and a reasonable period > > of time to take a looksie, but I wouldn't hold the patch for long due to > > a Silvermont tuning issue. > > Leave pr65105-3.c to fail for now. We can take a look later.
I have a patch for this. The problem is with conversion of COMPARE, which gets assigned to SImode chain, while in fact we expect very specific form of DImode compare. Uros.
