This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Is MODES_TIEABLE_P transitive?
- From: Michael Meissner <meissner at linux dot vnet dot ibm dot com>
- To: gcc at gcc dot gnu dot org
- Date: Thu, 21 Apr 2016 15:53:47 -0400
- Subject: Is MODES_TIEABLE_P transitive?
- Authentication-results: sourceware.org; auth=none
As I start to allow integer modes into vector registers, I need to revisit
MODES_TIEABLE_P. I'm wondering if MODES_TIEABLE_P is transitive?
For example, with the current Power8 system
1) Anything can go in GPRs
2) Currently, SFmode/DFmode/KFmode, and vectors can go in VSX registers
(the first 32 are overlaid on top of the traditional floating point
registers, and the remaining 32 are overload on top of the traditional
Altivec registers).
3) At the moment, DImode can only go in the traditional floating point
registers, but I have patches to allow it in the traditional Altivec
registers as well.
4) The decimal types and the IBM extended double (SDmode, DDmode, TDmode,
and IFmode/TFmode) can only go in the traditional floating point
registers, and not the Altivec registers. In addition, for the 128-bit
types (TDmode, IFmode, TFmode) take two registers and not one, even
though the VSX registers are now 128-bits.
5) The current machines have the ability to load SImode into VSX registers
and store them. However, GCC has never allowed SImode in the floating
point or vector registers. Where we use it in the context of conversion
to/from floating point, we wrap in UNSPECs to hide the usage.
6) The next machine will have the ability to load and store 8/16-bit
values (QImode/HImode) to/from VSX registers.
What I'd like to do, in a Power8 context, is to allow these to return true
(after allowing SImode to go in VSX registers):
MODES_TIEABLE_P (SImode, DFmode)
MODES_TIEABLE_P (SImode, QImode)
but, the following would return false for power8:
MODES_TIEABLE_P (QImode, DFmode)
In a power9 context, since there are loads/stores of 8/16-bit items it would
return true.
If it matters, we would be switching to LRA in the GCC 7.0 time frame once PR
69847 is fixed (this is the spec 2006 403.gcc benchmark that slows down because
LRA is generating unnecessary address reloads because it doesn't use
LEGITIMIZE_RELOAD_ADDRESS.
So the question is whether we might need to support MODES_TIEABLE_P being
transitive (i.e. it would return true a lot less of the time). I would prefer
to not have to worry about odd corner cases where another type is tieable with
one of the arguments, but not tieable with the other. And does it matter
whether we are using RELOAD or IRA?
Thanks in advance.
--
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meissner@linux.vnet.ibm.com, phone: +1 (978) 899-4797