This is the mail archive of the gcc@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: Floating point registers vs. LOAD_EXTEND_OP on alpha


> Hopefully, this analysis is enough for an alpha maintainer to determine
> whether Joern needs an additional check in his post-reload patch or if
> the alpha backend's LOAD_EXTEND_OP should claim to be extending in these
> modes.

P.S.: A more useful change of LOAD_EXTEND_OP would say that the extension
only widens as far as it can without increasing the number of hard registers.
Or that it just doesn't apply to registers that are smaller than word_mode.

That would allow the SHmedia port to use LOAD_EXTEND_OP for SImode.

That leaves the question how to best implement this in the register
allocator.

Maybe we are just trying to hard to keep a nice hack working without changing
the way the RTL looks during combine.  It would seem that things would
be much saner if we required that an extend pattern much exist to match
LOAD_EXTEND_OP for it to be effective, and when combine makes use if it, it
replaces the load with a SIGN_EXTEND / ZERO_EXTEND as appropriate.
(The code in cse does appear to already replace some MEMs with a
 copy from a sign / zero extension, rather than the other way round.)

The main problem with this approach seems to keep track of when an
extension is actually used.  The tangle of last_value and cached
sign and 'non'zero bits makes me wonder if it might be easier to make
a register width aware flow pass for arbitrary integer modes <= word_mode.


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