Quoting DJ Delorie <d...@redhat.com>:
I suggest making reload reload the PSImode subreg instead, and
make the m32c machine description provide for a tertiary
reload so that the value can be loaded & truncated.
/
Don't know how to set up a tertiary reload (it's not documented
anywhere).
It's simply a secondary reload of a secondary reload. When a secondary
reload is recognized as a reload than cannot be made directly, a tertiary
reload is set up.
E.g. on the SH, for TARGET_SHCOMPACT, when you load a floating-point
register in SImode from memory which is in a high stack slot, you
first have a secondary reload in FPUL_REGS, than that reload gets
a secondary reload in GENERAL_REGS, then that reload needs an
address reload for the sum of the stack/frame pointer and the stack slot
offset.
From looking at the m32c machine description I got the impression that
you can't directly load A_REGS in PSImode from a PSImode subreg of a
SImode memory location, but maybe I was mistaken.
Is this the type of patch you're thining about? It seems to compile
that problem case, but I haven't tried anything else yet.
Index: config/m32c/m32c.c
===================================================================
--- config/m32c/m32c.c (revision 146617)
+++ config/m32c/m32c.c (working copy)
@@ -2040,12 +2040,37 @@ m32c_legitimize_reload_address (rtx * x,
It had crossed my mind that you could use LEGITIMIZE_RELOAD_ADDRESS to
hide the issue, but that is not the purpose of LEGITIMIZE_RELOAD_ADDRESS;
it should be used only to improve efficiency of reloading; if you can
get the same reloads with the macros and hooks that drive the generic
reload machinery, that is preferred. If there is no way to get a
working set of reloads that way, this points to a deficiency in the
target-independent reload code. Fixing that deficiency is generally harder
initially, but than you should be able to forget about the problem instead
of needing to fix it for N targets and have expensive maintenance if the
reload internals change.
What I was actually talking about was a patch to reload itself to make it
reload the SUBREG:PSI instead of the inside of the subreg.
It is possible that that would best be done using a new target macro or
hook, although you could auto-detect the special circumstances the m32r has
here, i.e. no hard register in base BASE_REG_CLASS (you'd really want
HARD_REGNO_NREGS outside of fixed_regs) being able to hold an integral mode
at least as wide as Pmode.
I would consider a patch using LEGITIMIZE_RELOAD_ADDRESS suitable for a
release branch where the emphasis is on not breaking anything else
(e.g. 4.4.x), or if you are working on a branch/fork that has little
prospect of being merged in the mainline in the near future, and want
to keep divergence in target-independent files low.
If you come to the conclusion that LEGITIMIZE_RELOAD_ADDRESS is actually
the best way to handle a class of reload correctness problems,
than we probably want a utility function or macro to be used in
LEGITIMIZE_RELOAD_ADDRESS that does this safely with less expected knowledge
of internal interfaces of reload on the part of the machine description
writer, and a change of tm.texi to document when and how to use the new
function/macro in LEGITIMIZE_RELOAD_ADDRESS.
