[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 #19 from Kazumoto Kojima <kkojima at gcc dot gnu.org> 2011-12-11 23:57:13 UTC ---
(In reply to comment #18)
The results look way better now.  I've tested your latest patch for
sh4-unknown-linux-gnu and found no new regressions for gcc testsuite.
CSiBE with "-O2 -fpic" on that target shows that 144 improvements and
28 dis-improvements for size on 896 files.  The worst case is
-4.34783 net/ipv4/ip_forward 704 736
which looks the case of the high r0 register pressure.  The best one is
25.7426 arch/testplatform/kernel/traps 10160 8080
which looks to be very impressive.

>   /* We want to enable the use of SUBREGs as a means to
>      VEC_SELECT a single element of a vector.  */
>+
>+  /* This effectively disallows using GENERAL_REGS for SFmode vector subregs.
>+     This can be problematic when SFmode vector subregs need to be accessed
>+     on the stack with displacement addressing, as it happens with -O0.
>+     Thus we allow the mode change for -O0.  */
>   if (to == SFmode && VECTOR_MODE_P (from) && GET_MODE_INNER (from) == SFmode)
>-    return (reg_classes_intersect_p (GENERAL_REGS, rclass));
>+    return optimize ? (reg_classes_intersect_p (GENERAL_REGS, rclass)) : false;

Rather than that, I guess that the QI/HImode disp addressing would
be an optimization unneeded for -O0 in the first place.  Perhaps
something like -mpreferdisp option and TARGET_PREFER_DISP macro
which are enable by default but disable at -O0 might be help.  It'll
also help some unfortunate anormallies for which those optimizations
will generate worse codes.

> There are probably smarter ways of doing what the patch does.  I have also
> tried out implementing it with predicates and constraints, few load/store insns
> and lots of alternatives in the insns.  However, reload would refuse to select
> the displacement addressing due to pressure on R0 in many cases.

Maybe.  Implementing it with predicates and constraints would be
smarter if possible but may be difficult because the register
allocator handles the "m" constraint specially.

> Would something like the attached patch be acceptable (after some cleanups)? 
> If so, I'd also start adding HImode displacement addressing support.

I think so, though we are in stage 3 and have to wait the trunk returns
to stage 1 or 2 for committing such changes.  You have the time for
implementing HImode support.
BTW, the changes for white spaces, spells and other clean-ups which
are not essential for this work should be separated into another patch.