https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90530
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |ra
CC| |vmakarov at gcc dot gnu.org
--- Comment #14 from Richard Biener <rguenth at gcc dot gnu.org> ---
(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.
