This is the mail archive of the gcc-patches@gcc.gnu.org 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: RFA: Fix PR middle-end/29847


Richard Sandiford wrote:

FWIW, I've looked at the patch for 29845 too, but could you explain
in more detail why you think this is the right fix? I would have
thought that matching constraints should always provide the least
significant end of the wider operand, and if gcc doesn't know which
end that is in a particular situation, it should be taught in a more
direct way. Introducing a target macro at the matching level seems
a bit hackish.


I don't know why the current behaviour is why it is, but someone has gone to
extra pains to make sure that the big endian adjustment is not made unless the
mode is a scalar integer mode. Maybe there is a target out there that has
big endian or bi-endian integer registers, but little-endian floating point registers.


As it happens, the SH has bi-endian integer registers and big endian floating point
registers, so if I wanted to have a matching operand for hardware floating point
registers, I could do this with the hook too, by always doing big endian adjustments
for floating point register numbers.


Although the SH port would be more efficient if the floating point registers were
internally numbered in gcc such that their endianness appears to match the
memory endianness.



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