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.
