This is the mail archive of the gcc@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]

Is MODES_TIEABLE_P transitive?


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


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