This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Status of SSE builtins
- From: Jan Hubicka <jh at suse dot cz>
- To: gcc at gcc dot gnu dot org, rth at cygnus dot com, bernds at redhat dot com, aj at suse dot de
- Date: Tue, 29 Oct 2002 15:36:08 +0100
- Subject: Status of SSE builtins
Hi,
after three weeks long bugfixing I think the SSE builtins are in pretty
working shape - all of them results in valid instructions, some in
suboptimal code (like *_set patterns).
There are critical bugs left tought:
1) Outgoing argument alignment
I blieve my last patch is mostly valid, but has not been reviewed
2) Stack aligmnment
The patches for dynamic stack alignment has been sent to the list
but never applied. Are there some plans about that?
When we don't have dynamic stack alignment we can:
a) Assume that ABI contains preffered-stack-alignment so the
entry point is always aligned
This gives us quite cheaply working SSE support
b) Assume that ABI does not mandate preffered-stack-alignment
This needs to teach all moves to output unaligned moves
depending on alignment setting in the MEM expression.
We also need to add target hook for x86-64 that should use a)
Most importantly we need to change predicates of all SSE
patterns to refuse missaligned memory operands. This will
break reload that will happily insert it on 'm' constraint so
we will have to duplicate all the patterns, one for 32bit and
one for 64bit version
3) ABI compatibility with ICC
ICC obviously uses register passing conventions in version 6.0,
however I din't found any official documentation with it.
4) Missaligned load/store buitins
The use of missaligned loads/stores results in GCC eventually
keeping the values in register and producing "internal" move for it
resulting in trap. I am not sure how to model this properly.
5) generic SIMD support is quite broken right now as SSE does not
allow scalar opration on elements of vectors registers, like Sparc and
other sane instruction sets most probably do. I am not quite sure how
to get arround here and I also think the RTL produced is invalid when
dealing with vectors containing elements smaller than word size.
We also should probably rename most of the patterns to match the
names gneeric SIMD support handles
I am also quite confused about dealing with vec_select that is
quite redundant with SUBREG. SSE builtins appears to use
vec_select while SIMD appears to use subreg.
Any ideas how to deal with these? In case these won't be fixed in 3.3,
should we document it in "known bugs"?
Honza