https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90530
--- Comment #15 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Richard Biener from comment #14) > (In reply to dave.anglin from comment #13) > > On 2019-05-20 6:26 a.m., rguenth at gcc dot gnu.org wrote: > > > most definitely a reload as > > > > > > +(insn 177 176 178 2 (set (reg:SI 52 %fr24) > > > + (subreg:SI (reg:DI 51 %fr23) 4)) -1 > > > + (nil)) > > > > > > which isn't recognized isn't good. I don't know PA on what it can > > > and what not but these kind of sets from subregs appear during RTL > > > expansion for > > This isn't recognized because the only way to do it in general is to spill > > reg:DI 51 to memory > > and to read it back in SI mode. > > Yeah, and for the C testcase it does... > > > Maybe we are lucky with the const_int > > because some values > > are forced constant pool. > > > > There are no convert instructions other than sf<=>df mode and loads don't > > zero extend as > > they do to the integer registers. > > > > As I said, pa_can_change_mode_class() is written to prevent mode changes in > > the FP registers: > > > > /* There is no way to load QImode or HImode values directly from memory > > to a FP register. SImode loads to the FP registers are not zero > > extended. On the 64-bit target, this conflicts with the definition > > of LOAD_EXTEND_OP. Thus, we can't allow changing between modes with > > different sizes in the floating-point registers. */ > > if (MAYBE_FP_REG_CLASS_P (rclass)) > > return false; > > > > My feeling is reload should respect pa_can_change_mode_class(). > > Maybe it's asking wrong since you have > > if (GET_MODE_SIZE (from) == GET_MODE_SIZE (to)) > return true; > > and the size of the SUBREG_REG is the same as the FP reg? You'd need > to debug here. The only uses of can_change_mode_class are from old reload.c and via REG_CAN_CHANGE_MODE_P (also mostly used from old reload). AFAICS pa is using LRA now.
