On Mon, Mar 28, 2022 at 06:59:14PM -0500, Segher Boessenkool wrote: > On Mon, Mar 28, 2022 at 12:28:55PM -0400, Michael Meissner wrote: > > In looking at PR target/99293, I noticed that the vsx_extract_<mode> > > pattern for V2DImode and V2DFmode only allowed traditional floating point > > registers, and it did not allow Altivec registers. The original code was > > written a few years ago when we used the old register allocator, and > > support for scalar floating point in Altivec registers was just being > > added to GCC. > > vsx_extract_<mode> is from 2009... How time flies :-) > > This comment is from 2016 though. Still before LRA was default for us > of course ;-)
The support for scalars in Altivec registers wasn't really done until the 2016 time frame. At the time I had tried to use VSX registers for this, but I could never get a reproducable case for the failure other one spec benchmark not building with some flags (most likely spec 2017's 521.wrf_r or spec 2006's 481.wrf). So I opted to just keep it limited to traditional FPR registers, and maybe fix it some time later. > If would have been nice if we had a testcase for this breakage, so that > we could now be confident it really has been fixed. But the "reload" > here likely means "old reload", so okay. Yes, it was the old reload. > > PR target/99293 > > It has essentially nothing to do with that PR, right? Or I just do not > see it, always a possibility of course. It was just that I noticed the change in looking at PR target/99293. I did remove the reference from the checkin commit. > > * config/rs6000/rs6000.md (vsx_extract_<mode>): Allow destination > > to be an Altivec register. > > ... to be any VSX register. Thanks. > Okay for trunk with those things fixed. Thanks! Done. -- Michael Meissner, IBM PO Box 98, Ayer, Massachusetts, USA, 01432 email: meiss...@linux.ibm.com
