This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Advise on choose_hard_reg_mode (IA64, PR 20802, builtin_apply4.c)


I am looking at the failure of builtin_apply4.c on IA64 (Linux and
HP-UX) and I tracked the problem down to the fact that builtin_apply and
builtin_apply_args are using reg_raw_mode to set the register modes in
the apply_result_mode and apply_args_mode arrays.  These modes are then
used to save/restore the registers.  reg_raw_mode, in turn, is set by
choose_hard_reg_mode() in init_reg_modes_once().

The problem is that choose_hard_reg_mode() is choosing DImode as the raw
mode for IA64 floating point registers because that is the largest
integer value that can fit in a IA64 FP register.  While it is true that
IA64 FP registers can hold a DImode integer value, we really want the
raw mode for an IA64 FP register to be XFmode or RFmode.  By using
DImode we are causing IA64 GCC to save/restore with ldf8/stf8 instead of
ldfd/stfd (or even better ldf.fill/stf.spill) and messing up the values
that are in those registers.

I am looking at opinions on how to fix choose_hard_reg_mode() to return
a better mode for IA64 FP registers.

One idea I had was to look at REGNO_REG_CLASS and only consider modes
where the class of the mode matches the class returned by
REGNO_REG_CLASS.

Another option was to have an optional macro that choose_hard_reg_mode()
could call to get the right mode (overriding its default behavour) or
to targetize choose_hard_reg_mode() so that a target could override it's
default behavour that way.

Opinions?

Steve Ellcey
sje@cup.hp.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]