This is the mail archive of the
mailing list for the GCC project.
Re: Is MODES_TIEABLE_P transitive?
- From: Michael Meissner <meissner at linux dot vnet dot ibm dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: Michael Meissner <meissner at linux dot vnet dot ibm dot com>, gcc at gcc dot gnu dot org
- Date: Mon, 2 May 2016 17:21:48 -0400
- Subject: Re: Is MODES_TIEABLE_P transitive?
- Authentication-results: sourceware.org; auth=none
- References: <20160421195347 dot GA31219 at ibm-tiger dot the-meissners dot org> <e4fd1d49-12e4-4985-738c-eb65e8e4b06f at redhat dot com>
On Mon, Apr 25, 2016 at 11:04:01AM -0600, Jeff Law wrote:
> On 04/21/2016 01:53 PM, Michael Meissner wrote:
> >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?
> I don't recall a need for it to be transitive. The only really
> special thing I remember about MODES_TIEABLE_P was its relation to
> HARD_REGNO_MODE_OK and the need for them to be consistent.
> >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
> So what this kindof setup would allow would be subregs more
> aggressively between SImode/DFmode and SImode/QImode, but would
> restrict QImode/DFmode.
> You may need to twiddle CANNOT_CHANGE_MODE_CLASS along the way.
> >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?
> IIRC MODES_TIEABLE_P was largely related to reloads [in]ability to
> handle certain subreg extractions -- like trying to extract a QImode
> subreg out of FP hard register and the like.
Yeah, this is getting rather complex. I recall trying to change MODES_TIEABLE_P
in the past, and back then having all sorts of reload issues.
I kind of want my cake and eat it too. On one hand, I want the primary integer
types to be tieable, and other hand, having 32/64-bit ints tieable with
floating point (things like IBM extended double and vectors can never be
tieable due to the extended double using 2 64-bit parts in 2 separate
registers, and vectors using a single 128-bit part in 1 register).
In particular, in power9 there are various instructions for packing and
unpacking floating point types, and it would be natural to want to use them for
unions to help speed up the math library (as well as the ability to do byte and
half-word memory operations). I will put it on the back burner for now.
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: email@example.com, phone: +1 (978) 899-4797