This is the mail archive of the
mailing list for the GCC project.
Advise on choose_hard_reg_mode (IA64, PR 20802, builtin_apply4.c)
- From: Steve Ellcey <sje at cup dot hp dot com>
- To: gcc-patches at gcc dot gnu dot org
- Date: Thu, 15 Jun 2006 16:32:40 -0700 (PDT)
- Subject: Advise on choose_hard_reg_mode (IA64, PR 20802, builtin_apply4.c)
- Reply-to: sje at cup dot hp dot com
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
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.