RFA: pervasive SSE codegen inefficiency
Dale Johannesen
dalej@apple.com
Thu Sep 15 01:21:00 GMT 2005
Consider the following SSE code
(-march=pentium4 -mtune=prescott -O2 -mfpmath=sse -msse2)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 4256776a.c
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20050915/e95e1d40/attachment.c>
-------------- next part --------------
The first inner loop compiles to
paddq %xmm0, %xmm1
Good. The second compiles to
movdqa %xmm2, %xmm0
paddw %xmm1, %xmm0
movdqa %xmm0, %xmm1
when it could be using a single paddw. The basic problem is that
our approach defines __m128i to be V2DI even though all the operations
on the object are V4SI, so there are a lot of subreg's that don't need
to generate code. I'd like to fix this, but am not sure how to go
about it.
The pattern-matching and RTL optimizers seem quite hostile to mismatched
mode operations. If I were starting from scratch I'd define a single
V128I mode
and distinguish paddw and paddq by operation codes, or possibly by using
subreg:SSEMODEI throughout the patterns. Any less intrusive ideas?
Thanks.
(ISTR some earlier discussion about this but can't find it; apologies if
I'm reopening something that shouldn't be:)
More information about the Gcc
mailing list