On 01/03/15 08:16, Eric Botcazou wrote:
I'm a little concerned about the MODES_TIEABLE_P definition, but if it's
working, I wouldn't mess with it.
Could you elaborate? Do you find it too restrictive?
I'm a little concerned it's too loose. Basically it says that if both
modes are integer modes, then they're tieable. However,
HARD_REGNO_MODE_OK may return different values for MODE1 and MODE2, even
if both are integer modes.
My recollection is if MODES_TIEABLE_P returns true for mode1 and mode2,
then HARD_REGNO_MODE_OK must return the same value when passed mode1 and
mode2 regardless of the hard register and it's not obvious if
HARD_REGNO_MODE_OK fits that criteria for this port.
Looking at the current docs, the language has been watered down from my
recollection. So.....
If it's working, then I'd leave it as-is.
Any thoughts on using LRA for this port? Ideally we want to be moving
away from reload as much as we can.
I can only promise to start experimenting with it and report issues, if any.
The port is quite mature and the performances are closely monitored so bold
changes need to be made with extra caution.
Understood.
FWIW, I suspect this is the last port I'll approve that doesn't use LRA
instead of reload.
Yes, I'm going to be the maintainer for now.
Given you're already maintaining other parts of GCC, I really just
consider appointing you as the maintainer for the port a formality.
I'll start that process, but go ahead and list yourself as the
maintainer in the MAINTAINERS file.
jeff
