http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55278
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |hubicka at gcc dot gnu.org,
| |uros at gcc dot gnu.org
--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Ok, I've looked a little bit on the #c6 testcase.
On i7-2600 CPU I get:
-O3 -mavx
1mo old gcc trunk 0m6.347s
1mo old gcc trunk reload 0m6.517s
curr trunk 0m6.049s
trunk unroll 0m5.800s
trunk unroll p1 0m5.671s
trunk unroll p1+p2 0m5.691s
clang 3.2 0m6.007s
clang 3.3 svn 0m6.003s
icc 0m5.364s
where unroll is -funroll-loops --param max-completely-peeled-insns=500 (to
match what icc does, which aggressively unrolls the huge inner loop that
iterates exactly 4 times), p1 is experimental hack:
+(define_insn "*<code>hi_1"
+ [(set (match_operand:HI 0 "nonimmediate_operand" "=r,rm")
+(any_or:HI
+ (match_operand:HI 1 "nonimmediate_operand" "%0,0")
+ (match_operand:HI 2 "general_operand" "rn,ri")))
+ (clobber (reg:CC FLAGS_REG))]
+ "ix86_binary_operator_ok (<CODE>, HImode, operands)"
+ "<logic>{l}\t{%k2, %k0|%k0, %k2}"
+ [(set_attr "type" "alu")
+ (set_attr "mode" "SI")])
(force gcc to avoid xorw memory, %hireg and instead use movzwl memory, %sireg;
... xorl %sireg, %sireg2) and p2 was something similar for *xorqi_1.
Looking at icc generated assembly, it is interesting to see that the only
HImode instructions it ever uses are rolw and movw stores, for everything else
it uses
movzwl loads and SImode arithmetics (well, I guess shift right shrw/sarw/rorw
can't be avoided either). Similarly, icc on the testcase doesn't emit any
QImode instructions at all, while gcc emits tons of them and llvm something in
between.
So perhaps this bug is not about LRA, but about instruction selection, and when
not optimizing for size at least on some CPUs we should consider using SImode
arithmetics instead of QImode/HImode much more aggressively than we do now.
Not sure if it is better done by (Kai's?) type optimization pass, which shortly
before expansion using target hints would just try to get rid of as many QImode
and especially HImode operations as possible, guess we can often keep complete
garbage in the upper bits, or if it is better done at the *.md level.
