This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
RFC: offsettable problem
- From: Dale Johannesen <dalej at apple dot com>
- To: gcc_mailing_list List <gcc at gcc dot gnu dot org>
- Cc: Dale Johannesen <dalej at apple dot com>, Geoffrey Keating <geoffk at apple dot com>, David Edelsohn <dje at watson dot ibm dot com>
- Date: Wed, 16 Jun 2004 16:36:18 -0700
- Subject: RFC: offsettable problem
This shows up on rs6000, but I think the rot goes deeper than that....
The rs6000 BE currently generates invalid assembly for this:
(insn:TI 478 481 482 isosurface.fppized.f90:1539 (set (mem:DF (plus:SI
(reg/f:SI 1 r1)
(const_int 32760 [0x7ff8])) [0 S8 A8])
(reg:DF 9 r9 [579])) 316 {*movdf_hardfloat32} (insn_list 4391
(insn_list 4390 (nil))))
This ought to be OK, it can generate
lwz r9, 32760(r1)
lwz r10, 32764(r1)
with all the offsets in range. (Presumably some earlier phase thought
so too.)
However, the movdf_hardfloat32 pattern calls
offsettable_address_p(1, DFmode, R1+32760)
which calls
mode_dependent_address_p(R1+32760)
which calls
GO_IF_MODE_DEPENDENT_ADDRESS
which gets back into the rs6000 code, which requires enough space for
TFmode, which
is not there in this edge case. It doesn't have a mode to work with
at that point, and is
actually rather more lenient than the description of
GO_IF_MODE_DEPENDENT_ADDRESS
says it ought to be (more on this below).
So I guess I can fix this by cloning offsettable_address_p in the
rs6000 BE and making it
do the right thing. (I'm not really interested in solutions that
accept the pattern above as
non-offsettable; the code you get that way is terrible, and it's Just
Wrong.)
But it looks to me like offsettable_address_p is wrong. It says
/* Return 1 if Y is a memory address which contains no side effects
and would remain valid after the addition of a positive integer
less than the size of that mode.
But that's not what it does. It calls mode_dependent_address, which
does not take
a mode, and is supposed to do this:
/* Return 1 if ADDR is an address-expression whose effect depends
on the mode of the memory reference it is used in.
And that calls GO_IF_MODE_DEPENDENT, which implements this, and that's
consistent with its documentation. But that's too restrictive for what
offsettable_address_p
wants to do.*
But this is low-level and has been around a while, so there's no way I
can change it
here without breaking things, right? Whoever put this rather
frustrated comment in
the rs6000 code seemed to think so:
/* Go to LABEL if ADDR (a legitimate address expression)
has an effect that depends on the machine mode it is used for.
On the RS/6000 this is true of all integral offsets (since AltiVec
modes don't allow them) or is a pre-increment or decrement.
??? Except that due to conceptual problems in offsettable_address_p
we can't really report the problems of integral offsets. So leave
this assuming that the adjustable offset must be valid for the
sub-words of a TFmode operand, which is what we had before. */
So do we actually know what will break? Suggestions?