http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50751
--- Comment #21 from Kazumoto Kojima <kkojima at gcc dot gnu.org> 2011-12-12
22:08:18 UTC ---
(In reply to comment #20)
> As far as I could observe it, this is mainly triggered by the following in
> sh_legitimate_index_p:
>
> + if (mode == QImode && (unsigned) INTVAL (op) < 16)
> + return true;
It seems that, with that hunk, recog.c:offsettable_address_addr_space_p
returns always true for V2SF mode. Without that hunk, it returns false
for that case. There are comments and lines in that function like
/* Use QImode because an odd displacement may be automatically invalid
for any wider mode. But it should be valid for a single byte. */
good = (*addressp) (QImode, y, as);
where addrssp is *memory_address_addr_space_p which returns true with
that hunk.
> You mean, by giving the user the option to turn off displacement addressing
> for
> e.g. some specific files / modules by specifying -mno-preferdisp or something
> like that? By anomalies do you mean code that gets worse because of too much
> pressure on R0 and all the reloads around it, or do you have any other bad use
> cases?
Yes and yes. Although I didn't look all dis-improvements,
it looks r0 pressure is the primary factor.
> Another thing I could try out is to have load/store insns that allow arbitrary
> operands in displacement addressing like on SH2A, and split them into two
> insns
> of one load/store and one reg-reg move after reload. But that would probably
> require the R0 clobber in the expander which could make worse code in cases
> where displacement addressing is not used, I guess.
> Do you think this approach could make sense?
I guess that it could make worse code in some situations as you say.
> Yep, sure. I've noticed that the latest version of the patch seems to fix
> some
> more testsuite failures. I will investigate which hunk is responsible for the
> fixes so that could be pulled out from the patch. OK?
Sounds great.
