This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Is MODES_TIEABLE_P transitive?
- From: Jeff Law <law at redhat dot com>
- To: Michael Meissner <meissner at linux dot vnet dot ibm dot com>, gcc at gcc dot gnu dot org
- Date: Mon, 25 Apr 2016 11:04:01 -0600
- 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>
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.
jeff