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

Re: [PATCH] Fix PR target/33923

> CANNOT_CHANGE_MODE_CLASS is intended for the case where a register can
> validly hold two different modes, but you can't convert between the
> modes by using a subreg.  The example given in the docs shows this.

OK.  But it is known that it is not necessary only for this case, see for 
example the x86 port with MMX and SSE registers.

> The IA-64 br regs case is different.  The br regs do not allow use of an
> SImode value, so SImode values should never occur in a br reg.  In
> practice, they do, because MODES_TIEABLE_P allows it.  This is an issue
> with the definition of MODES_TIEABLE_P.  If we fixed MODES_TIEABLE_P,
> then we would not need a CANNOT_CHANGE_MODE_CLASS change here.

I'd dispute that.  MODES_TIEABLE_P is only used for local register allocation; 
in particular, it is totally ignored by the class selection code.  The latter 
only knows about HARD_REGNO_MODE_OK and CANNOT_CHANGE_MODE_CLASS; now, since
HARD_REGNO_MODE_OK is not sufficient as the example shows, I think that the 
CANNOT_CHANGE_MODE_CLASS change is needed independently of MODES_TIEABLE_P.

> If you still don't understand the point I am trying to make, that is OK.
> Just go ahead and check in your patch and I will update the comment.

I'm going to do so.  Thanks again.

Eric Botcazou

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