Is MODES_TIEABLE_P transitive?

Jeff Law
Mon Apr 25 17:04:00 GMT 2016

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.


More information about the Gcc mailing list