[Bug target/50751] SH Target: Displacement addressing does not work for QImode and HImode

["kkojima at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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.