Fix SPEC2000 GCC misscopilation and SIMD support
Jan Hubicka
jh@suse.cz
Tue Dec 10 15:20:00 GMT 2002
> On Tue, Dec 10, 2002 at 11:51:18PM +0100, Jan Hubicka wrote:
> > This is of course not issue for 3.3 where SSE builtins generate lousy
> > code in other cases, but in future I think we should manage to convert
> > a into subreg of b.
> >
> > Do you see such longer term plan without using the subregs?
>
> Well, some sort of vector extract and vector insert operations.
This won't handle the case perfectly We do have
(define_insn "sse_storess"
[(set (match_operand:SF 0 "memory_operand" "=m")
(vec_select:SF
(match_operand:V4SF 1 "register_operand" "x")
(parallel [(const_int 0)])))]
"TARGET_SSE"
"movss\t{%1, %0|%0, %1}"
[(set_attr "type" "ssemov")
(set_attr "mode" "SF")])
that can be used to handle the register case too, but still we won't
optimize references to a into (subreg b) so we will end up with extra
movss produced (and increased register pressure).
Not that big deal, but still it would be nice.
>
> > I know we do have VEC_SELECT construct that in some ways is equivalent
> > to SUBREG (ie we can just manage to have VEC_SELECTS in all operations
> > on a) but that would mean to teach combine, regmove and similar mess
> > that VEC_SELECT is SUBREG-like construct...
>
> It has similarities, but would be substantially better defined.
> It would not carry the kind of baggage that SUBREG "enjoys".
Uhm yes.
I am not quite sure if we won't end up with same kind of mess in longer
run, just duplicated twice. But I see there are good reasons to stay
away from subregs :)
I will definitly bootstrap and submit the patch for nonparadoxical
subregs sometime tomorrow.
Honza
>
>
> r~
More information about the Gcc-patches
mailing list