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