Re: Vector modes under hppa64-hpu

Re: Vector modes under hppa64-hpu

[Steve Ellcey]

>  > Well, following up to my own mail, I have a couple of questions.  If I
>  > am on a system that does not support the VECTOR modes, should I ever see
>  > any rtx with a type of V2SImode?  I don't think I should, but I am
>  > not
> 
> yes.  It should opencode the V2SI with a pair of SIs.

I don't understand exactly what you mean by "opencode" but I assume you
are saying that it is OK to generate V2SI rtx nodes and they they will
get transformed into two SImode nodes at some point.  Is there a single
place where this transformation happens?  If so, where?

Steve Ellcey
sje@cup.hp.com

Re: Vector modes under hppa64-hpu

[Aldy Hernandez]

> I don't understand exactly what you mean by "opencode" but I assume you

see optabs.c:expand_vector_binop()

> are saying that it is OK to generate V2SI rtx nodes and they they will
> get transformed into two SImode nodes at some point.  Is there a
> single

yes.

> place where this transformation happens?  If so, where?

optabs.c

Re: Vector modes under hppa64-hpu

[Joern Rennecke]

>> Well, following up to my own mail, I have a couple of questions.  If I
>> am on a system that does not support the VECTOR modes, should I ever see
>> any rtx with a type of V2SImode?  I don't think I should, but I am
>> not
>
>yes.  It should opencode the V2SI with a pair of SIs.

It should be OK to use V2SImode as long as only subregs of that appear in operands
of insns.  e.g. if the targets supports DImode, you could move a V2SImode value
using DImode.
	
-- 
--------------------------
SuperH
2430 Aztec West / Almondsbury / BRISTOL / BS32 4AQ
T:+44 1454 462330

Re: Vector modes under hppa64-hpu

[John David Anglin]

Testing with current cvs under hppa-linux is no longer possible.  The
following build error occurs:

./xgcc -B./ -B/home/dave/opt/gnu/hppa-linux/bin/ -isystem /home/dave/opt/gnu/hppa-linux/include -isystem /home/dave/opt/gnu/hppa-linux/sys-include -O2  -DIN_GCC    -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -isystem ./include  -fPIC -DELF=1 -DLINUX=1 -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED  -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/config -I../../gcc/gcc/../include  -DL_muldi3 -c ../../gcc/gcc/libgcc2.c -o libgcc/./_muldi3.o
In file included from ../../gcc/gcc/libgcc2.c:44:
../../gcc/gcc/libgcc2.h:80:5: warning: integer overflow in preprocessor expression
../../gcc/gcc/libgcc2.h:97:5: warning: integer overflow in preprocessor expression
../../gcc/gcc/libgcc2.h:100:5: warning: integer overflow in preprocessor expression
In file included from ../../gcc/gcc/libgcc2.c:44:
../../gcc/gcc/libgcc2.h:219: error: parse error before "__muldi3"
../../gcc/gcc/libgcc2.h:219: warning: type defaults to `int' in declaration of `__muldi3'
../../gcc/gcc/libgcc2.h:219: warning: parameter names (without types) in function declaration
../../gcc/gcc/libgcc2.h:219: warning: data definition has no type or storage class
../../gcc/gcc/libgcc2.h:220: error: parse error before "__divdi3"
../../gcc/gcc/libgcc2.h:220: warning: type defaults to `int' in declaration of `__divdi3'
../../gcc/gcc/libgcc2.h:220: warning: parameter names (without types) in function declaration
../../gcc/gcc/libgcc2.h:220: warning: data definition has no type or storage class
../../gcc/gcc/libgcc2.h:221: error: parse error before "__udivdi3"
../../gcc/gcc/libgcc2.h:221: warning: type defaults to `int' in declaration of `__udivdi3'
../../gcc/gcc/libgcc2.h:221: warning: parameter names (without types) in function declaration
../../gcc/gcc/libgcc2.h:221: warning: data definition has no type or storage class
../../gcc/gcc/libgcc2.h:222: error: parse error before "__umoddi3"
../../gcc/gcc/libgcc2.h:222: warning: type defaults to `int' in declaration of `__umoddi3'
../../gcc/gcc/libgcc2.h:222: warning: parameter names (without types) in function declaration
../../gcc/gcc/libgcc2.h:222: warning: data definition has no type or storage class
../../gcc/gcc/libgcc2.h:223: error: parse error before "__moddi3"
../../gcc/gcc/libgcc2.h:223: warning: type defaults to `int' in declaration of `__moddi3'
../../gcc/gcc/libgcc2.h:223: warning: parameter names (without types) in function declaration
../../gcc/gcc/libgcc2.h:223: warning: data definition has no type or storage class
../../gcc/gcc/libgcc2.h:228: error: parse error before "__udivmoddi4"
../../gcc/gcc/libgcc2.h:228: error: parse error before '*' token
../../gcc/gcc/libgcc2.h:228: warning: type defaults to `int' in declaration of `__udivmoddi4'
../../gcc/gcc/libgcc2.h:228: warning: function declaration isn't a prototype
../../gcc/gcc/libgcc2.h:228: warning: data definition has no type or storage class
../../gcc/gcc/libgcc2.h:233: error: parse error before "__negdi2"
../../gcc/gcc/libgcc2.h:233: warning: type defaults to `int' in declaration of `__negdi2'
../../gcc/gcc/libgcc2.h:233: warning: parameter names (without types) in function declaration
../../gcc/gcc/libgcc2.h:233: warning: data definition has no type or storage class
../../gcc/gcc/libgcc2.h:236: error: parse error before "__lshrdi3"
../../gcc/gcc/libgcc2.h:236: error: parse error before "word_type"
../../gcc/gcc/libgcc2.h:236: warning: type defaults to `int' in declaration of `__lshrdi3'
../../gcc/gcc/libgcc2.h:236: warning: function declaration isn't a prototype
../../gcc/gcc/libgcc2.h:236: warning: data definition has no type or storage class
../../gcc/gcc/libgcc2.h:237: error: parse error before "__ashldi3"
../../gcc/gcc/libgcc2.h:237: error: parse error before "word_type"
../../gcc/gcc/libgcc2.h:237: warning: type defaults to `int' in declaration of `__ashldi3'
../../gcc/gcc/libgcc2.h:237: warning: function declaration isn't a prototype
../../gcc/gcc/libgcc2.h:237: warning: data definition has no type or storage class
../../gcc/gcc/libgcc2.h:238: error: parse error before "__ashrdi3"
../../gcc/gcc/libgcc2.h:238: error: parse error before "word_type"
../../gcc/gcc/libgcc2.h:238: warning: type defaults to `int' in declaration of `__ashrdi3'
../../gcc/gcc/libgcc2.h:238: warning: function declaration isn't a prototype
../../gcc/gcc/libgcc2.h:238: warning: data definition has no type or storage class
../../gcc/gcc/libgcc2.h:239: error: parse error before "__ffsdi2"
../../gcc/gcc/libgcc2.h:239: warning: type defaults to `int' in declaration of `__ffsdi2'
../../gcc/gcc/libgcc2.h:239: warning: parameter names (without types) in function declaration
../../gcc/gcc/libgcc2.h:239: warning: data definition has no type or storage class
../../gcc/gcc/libgcc2.h:247: warning: parameter names (without types) in function declaration
../../gcc/gcc/libgcc2.h:248: warning: parameter names (without types) in function declaration
../../gcc/gcc/libgcc2.h:251: error: parse error before "__absvdi2"
../../gcc/gcc/libgcc2.h:251: warning: type defaults to `int' in declaration of `__absvdi2'
../../gcc/gcc/libgcc2.h:251: warning: parameter names (without types) in function declaration
../../gcc/gcc/libgcc2.h:251: warning: data definition has no type or storage class
../../gcc/gcc/libgcc2.h:253: error: parse error before "__addvdi3"
../../gcc/gcc/libgcc2.h:253: warning: type defaults to `int' in declaration of `__addvdi3'
../../gcc/gcc/libgcc2.h:253: warning: parameter names (without types) in function declaration
../../gcc/gcc/libgcc2.h:253: warning: data definition has no type or storage class
../../gcc/gcc/libgcc2.h:255: error: parse error before "__subvdi3"
../../gcc/gcc/libgcc2.h:255: warning: type defaults to `int' in declaration of `__subvdi3'
../../gcc/gcc/libgcc2.h:255: warning: parameter names (without types) in function declaration
../../gcc/gcc/libgcc2.h:255: warning: data definition has no type or storage class
../../gcc/gcc/libgcc2.h:257: error: parse error before "__mulvdi3"
../../gcc/gcc/libgcc2.h:257: warning: type defaults to `int' in declaration of `__mulvdi3'
../../gcc/gcc/libgcc2.h:257: warning: parameter names (without types) in function declaration
../../gcc/gcc/libgcc2.h:257: warning: data definition has no type or storage class
../../gcc/gcc/libgcc2.h:259: error: parse error before "__negvdi2"
../../gcc/gcc/libgcc2.h:259: warning: type defaults to `int' in declaration of `__negvdi2'
../../gcc/gcc/libgcc2.h:259: warning: parameter names (without types) in function declaration
../../gcc/gcc/libgcc2.h:259: warning: data definition has no type or storage class
../../gcc/gcc/libgcc2.h:262: error: parse error before "__fixdfdi"
../../gcc/gcc/libgcc2.h:262: warning: type defaults to `int' in declaration of `__fixdfdi'
../../gcc/gcc/libgcc2.h:262: warning: data definition has no type or storage class
../../gcc/gcc/libgcc2.h:263: error: parse error before "__fixsfdi"
../../gcc/gcc/libgcc2.h:263: warning: type defaults to `int' in declaration of `__fixsfdi'
../../gcc/gcc/libgcc2.h:263: warning: data definition has no type or storage class
../../gcc/gcc/libgcc2.h:264: warning: parameter names (without types) in function declaration
../../gcc/gcc/libgcc2.h:265: warning: parameter names (without types) in function declaration
../../gcc/gcc/libgcc2.h:268: error: parse error before "__fixunsdfdi"
../../gcc/gcc/libgcc2.h:268: warning: type defaults to `int' in declaration of `__fixunsdfdi'
../../gcc/gcc/libgcc2.h:268: warning: data definition has no type or storage class
../../gcc/gcc/libgcc2.h:269: error: parse error before "__fixunssfdi"
../../gcc/gcc/libgcc2.h:269: warning: type defaults to `int' in declaration of `__fixunssfdi'
../../gcc/gcc/libgcc2.h:269: warning: data definition has no type or storage class
../../gcc/gcc/libgcc2.h:271:5: warning: integer overflow in preprocessor expression
../../gcc/gcc/libgcc2.h:278:5: warning: integer overflow in preprocessor expression
../../gcc/gcc/libgcc2.h:301: error: parse error before "DItype"
../../gcc/gcc/libgcc2.h:301: warning: no semicolon at end of struct or union
../../gcc/gcc/libgcc2.h:302: warning: type defaults to `int' in declaration of `DWunion'
../../gcc/gcc/libgcc2.h:302: warning: data definition has no type or storage class
../../gcc/gcc/libgcc2.c:349: error: parse error before "__muldi3"
../../gcc/gcc/libgcc2.c:349: error: parse error before "u"
../../gcc/gcc/libgcc2.c:350: warning: return type defaults to `int'
../../gcc/gcc/libgcc2.c:350: warning: function declaration isn't a prototype
../../gcc/gcc/libgcc2.c: In function `__muldi3':
../../gcc/gcc/libgcc2.c:351: error: parse error before "w"
../../gcc/gcc/libgcc2.c:354: error: `uu' undeclared (first use in this function)
../../gcc/gcc/libgcc2.c:354: error: (Each undeclared identifier is reported only once
../../gcc/gcc/libgcc2.c:354: error: for each function it appears in.)
../../gcc/gcc/libgcc2.c:354: error: `u' undeclared (first use in this function)
../../gcc/gcc/libgcc2.c:355: error: `vv' undeclared (first use in this function)
../../gcc/gcc/libgcc2.c:355: error: `v' undeclared (first use in this function)
../../gcc/gcc/libgcc2.c:355: warning: left-hand operand of comma expression has no effect
../../gcc/gcc/libgcc2.c:357: error: `w' undeclared (first use in this function)
../../gcc/gcc/libgcc2.c:357: error: parse error before "__w"
../../gcc/gcc/libgcc2.c:357: error: `__w' undeclared (first use in this function)
make[3]: *** [libgcc/./_muldi3.o] Error 1
make[3]: Leaving directory `/home/dave/gcc-3.2/objdir/gcc'
make[2]: *** [libgcc.a] Error 2
make[2]: Leaving directory `/home/dave/gcc-3.2/objdir/gcc'
make[1]: *** [stage2_build] Error 2
make[1]: Leaving directory `/home/dave/gcc-3.2/objdir/gcc'
make: *** [bootstrap] Error 2

Previous successful build was as of

LAST_UPDATED: Thu Jul 25 15:16:07 UTC 2002

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: Vector modes under hppa64-hpu

[Joern Rennecke]

  	  else
  	    t = simplify_gen_subreg (submode, target, mode, i * subsize);
! 	  if (CONSTANT_P (op0) || GET_CODE (op0) == REG)
  	    a = simplify_gen_subreg (submode, op0, mode, i * subsize);
  	  else
  	    a = extract_bit_field (op0, subbitsize, i * subbitsize, unsignedp,
  				   NULL_RTX, submode, submode, size);
! 	  if (CONSTANT_P (op1) || GET_CODE (op1) == REG)
  	    b = simplify_gen_subreg (submode, op1, mode, i * subsize);
  	  else
  	    b = extract_bit_field (op1, subbitsize, i * subbitsize, unsignedp,


That doesn't work when submode is smaller than a word.  At register allocation
time, every subreg of a single hard register is assumed to be a low part,
even if its not.

-- 
--------------------------
SuperH
2430 Aztec West / Almondsbury / BRISTOL / BS32 4AQ
T:+44 1454 462330

Re: Vector modes under hppa64-hpu

[Aldy Hernandez]

On Thu, Jul 25, 2002 at 09:49:55PM +0100, Joern Rennecke wrote:
>   	  else
>   	    t = simplify_gen_subreg (submode, target, mode, i * subsize);
> ! 	  if (CONSTANT_P (op0) || GET_CODE (op0) == REG)
>   	    a = simplify_gen_subreg (submode, op0, mode, i * subsize);
>   	  else
>   	    a = extract_bit_field (op0, subbitsize, i * subbitsize, unsignedp,
>   				   NULL_RTX, submode, submode, size);
> ! 	  if (CONSTANT_P (op1) || GET_CODE (op1) == REG)
>   	    b = simplify_gen_subreg (submode, op1, mode, i * subsize);
>   	  else
>   	    b = extract_bit_field (op1, subbitsize, i * subbitsize, unsignedp,
> 
> 
> That doesn't work when submode is smaller than a word.  At register allocation
> time, every subreg of a single hard register is assumed to be a low part,
> even if its not.

Can you take a look at his failure then?  It's preproducible with a
cross compiler, you just need to build cc1 on:

hppa1.0-hp-hpux11.00

aldy

Re: Vector modes under hppa64-hpu

[Joern Rennecke]

[-- Attachment #1: Type: text/plain, Size: 284 bytes --]

Aldy Hernandez wrote:
> Can you take a look at his failure then?  It's preproducible with a
> cross compiler, you just need to build cc1 on:
> 
> hppa1.0-hp-hpux11.00
> 
> aldy

-- 
--------------------------
SuperH
2430 Aztec West / Almondsbury / BRISTOL / BS32 4AQ
T:+44 1454 462330

[-- Attachment #2: pa-fix --]
[-- Type: text/plain, Size: 1022 bytes --]

Thu Jul 25 23:00:13 2002  J"orn Rennecke <joern.rennecke@superh.com>

	* pa.md (extv): Check predicates before emitting extv_32.

Index: config/pa/pa.md
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/pa/pa.md,v
retrieving revision 1.109
diff -p -r1.109 pa.md
*** config/pa/pa.md	11 Jul 2002 18:47:45 -0000	1.109
--- config/pa/pa.md	25 Jul 2002 22:00:04 -0000
***************
*** 6658,6665 ****
      emit_insn (gen_extv_64 (operands[0], operands[1],
  			    operands[2], operands[3]));
    else
!     emit_insn (gen_extv_32 (operands[0], operands[1],
! 			    operands[2], operands[3]));
    DONE;
  }")
  
--- 6658,6670 ----
      emit_insn (gen_extv_64 (operands[0], operands[1],
  			    operands[2], operands[3]));
    else
!     {
!       if (! uint5_operand (operands[2], SImode)
! 	  || ! uint5_operand (operands[3], SImode))
! 	FAIL;
!       emit_insn (gen_extv_32 (operands[0], operands[1],
! 			      operands[2], operands[3]));
!     }
    DONE;
  }")
  

Re: Vector modes under hppa64-hpu

[John David Anglin]

> Thu Jul 25 23:00:13 2002  J"orn Rennecke <joern.rennecke@superh.com>
> 
> 	* pa.md (extv): Check predicates before emitting extv_32.

Installed on main.  Tested on hppa-linux.

Thanks,
Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: Vector modes under hppa64-hpu

[Aldy Hernandez]

>>>>> "Joern" == Joern Rennecke <joern.rennecke@superh.com> writes:

 >   	  else
 >   	    t = simplify_gen_subreg (submode, target, mode, i * subsize);
 > ! 	  if (CONSTANT_P (op0) || GET_CODE (op0) == REG)
 >   	    a = simplify_gen_subreg (submode, op0, mode, i * subsize);
 >   	  else
 >   	    a = extract_bit_field (op0, subbitsize, i * subbitsize, unsignedp,
 >   				   NULL_RTX, submode, submode, size);
 > ! 	  if (CONSTANT_P (op1) || GET_CODE (op1) == REG)
 >   	    b = simplify_gen_subreg (submode, op1, mode, i * subsize);
 >   	  else
 >   	    b = extract_bit_field (op1, subbitsize, i * subbitsize, unsignedp,


 > That doesn't work when submode is smaller than a word.  At register allocation
 > time, every subreg of a single hard register is assumed to be a low part,
 > even if its not.

Joern.  Could we keep the above code and add a check for the submode
being >= word?  It seems like the extract_bit_field is a bit of
overkill when the submode is just the word size.

What do you think?

Aldy

Re: Vector modes under hppa64-hpu

[Richard Henderson]

On Fri, Jul 26, 2002 at 09:30:39PM -0700, Aldy Hernandez wrote:
> Joern.  Could we keep the above code and add a check for the submode
> being >= word?  It seems like the extract_bit_field is a bit of
> overkill when the submode is just the word size.

One of the first things that extract_bit_field does is check for
the easy aligned case.  I think you should leave it alone.


r~

Re: Vector modes under hppa64-hpu

[Steve Ellcey]

I didn't do a full test suite run but it does fix simd-2 and simd-4 on
PA32 (the only simd failures I had last night).

Steve Ellcey
sje@cup.hp.com

> It looks like it's Joern's new simd code that's generating your bad
> instruction.  I have a quick fix for this [untested].  Can you give it
> a whirl and run tests?
> 
> Aldy

Re: Vector modes under hppa64-hpu

[Aldy Hernandez]

On Thu, Jul 25, 2002 at 12:27:35PM -0700, Steve Ellcey wrote:
> I didn't do a full test suite run but it does fix simd-2 and simd-4 on
> PA32 (the only simd failures I had last night).

Ok.  Please do a full test suite run, as I don't have a PA box.

Aldy

Re: Vector modes under hppa64-hpu

[Steve Ellcey]

> With a checkout yesterday evening, I can confirm that simd-1.c no
> longers fails on hppa64-hp-hpux11.00.  On the minus side, there are
> a whole bunch on new regressions in other areas.

I got a pass on simd-1.c too.  I ran tests on PA32, PA64, and IA64;
while simd-1.c passed on all of them simd-2 and simd-4 failed on PA32
(hppa1.1-hp-hpux11.00) with -O2 but passed on PA64 or IA64.  On PA32 I
got:

[hpsje - sje_merge] $ obj_pa_gcc/gcc/cc1 -O2 simd-2.c
 tempf
simd-2.c: In function `tempf':
simd-2.c:17: error: unrecognizable insn:
(insn 24 23 25 0 7afa84c0 (set (subreg:SI (reg:SF 105) 0)
        (sign_extract:SI (subreg:SI (reg:DI 104) 0)
            (const_int 32 [0x20])
            (const_int 0 [0x0]))) -1 (insn_list 23 (nil))
    (nil))
simd-2.c:17: internal compiler error: Internal compiler error in extract_insn, at recog.c:2163
Please submit a full bug report,


Steve Ellcey
sje@cup.hp.com

Re: Vector modes under hppa64-hpu

[Aldy Hernandez]

> I got a pass on simd-1.c too.  I ran tests on PA32, PA64, and IA64;
> while simd-1.c passed on all of them simd-2 and simd-4 failed on PA32
> (hppa1.1-hp-hpux11.00) with -O2 but passed on PA64 or IA64.  On PA32 I
> got:
> 
> [hpsje - sje_merge] $ obj_pa_gcc/gcc/cc1 -O2 simd-2.c
>  tempf
> simd-2.c: In function `tempf':
> simd-2.c:17: error: unrecognizable insn:

Hi Steve.

It looks like it's Joern's new simd code that's generating your bad
instruction.  I have a quick fix for this [untested].  Can you give it
a whirl and run tests?

Aldy

2002-07-25  Aldy Hernandez  <aldyh@redhat.com>

	* optabs.c (expand_vector_binop): Call simplify_gen_subreg if op
	is a register.


Index: optabs.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/optabs.c,v
retrieving revision 1.141
diff -c -p -r1.141 optabs.c
*** optabs.c	22 Jul 2002 14:22:58 -0000	1.141
--- optabs.c	25 Jul 2002 19:13:27 -0000
*************** expand_vector_binop (mode, binoptab, op0
*** 1973,1984 ****
  	    t = NULL_RTX;
  	  else
  	    t = simplify_gen_subreg (submode, target, mode, i * subsize);
! 	  if (CONSTANT_P (op0))
  	    a = simplify_gen_subreg (submode, op0, mode, i * subsize);
  	  else
  	    a = extract_bit_field (op0, subbitsize, i * subbitsize, unsignedp,
  				   NULL_RTX, submode, submode, size);
! 	  if (CONSTANT_P (op1))
  	    b = simplify_gen_subreg (submode, op1, mode, i * subsize);
  	  else
  	    b = extract_bit_field (op1, subbitsize, i * subbitsize, unsignedp,
--- 1973,1984 ----
  	    t = NULL_RTX;
  	  else
  	    t = simplify_gen_subreg (submode, target, mode, i * subsize);
! 	  if (CONSTANT_P (op0) || GET_CODE (op0) == REG)
  	    a = simplify_gen_subreg (submode, op0, mode, i * subsize);
  	  else
  	    a = extract_bit_field (op0, subbitsize, i * subbitsize, unsignedp,
  				   NULL_RTX, submode, submode, size);
! 	  if (CONSTANT_P (op1) || GET_CODE (op1) == REG)
  	    b = simplify_gen_subreg (submode, op1, mode, i * subsize);
  	  else
  	    b = extract_bit_field (op1, subbitsize, i * subbitsize, unsignedp,

Re: Vector modes under hppa64-hpu

[Steve Ellcey]

I'll try updating my sources and see if I can still reproduce it.  It
may be tomorrow before I have a chance to get back to you on my
success/failure.

Steve Ellcey
sje@cup.hp.com

> flamingo:~/build/pa64/gcc$ ./cc1 a.c -O2 -quiet
> flamingo:~/build/pa64/gcc$ ./cc1 a.c -O1 -quiet
> flamingo:~/build/pa64/gcc$ ./cc1 a.c -O -quiet
> flamingo:~/build/pa64/gcc$ 
> 
> no problem here either.  This is with a checkout from cvs as of right
> now.
> 
> 
> Aldy

Re: Vector modes under hppa64-hpu

[Steve Ellcey]

> Can you post x.c so I can try to debug this?

Sorry, x.c is just gcc.c-torture/compile/simd-1.c, I rename all my tests
to x.c when I work on them.

$ cat x.c
typedef int v2si __attribute__ ((mode(V2SI)));
typedef unsigned di __attribute__ ((mode(DI)));
void foo(unsigned long);
void bar() {
    v2si x = { 1, 2 };
    foo((di) x);
}

> Also, can I can make a cross ia64-hpux (or whatever) to reproduce your
> error, as I don't have neither an ia64 nor a pa64.

I don't know if building a cross ia64-hpux will work or not, but a pa64
version should at least build cc1.  These two platforms are behaving
slightly differently for me.  I can make IA64 work at all optimization
levels with the change that I included in my earlier mail
(http://gcc.gnu.org/ml/gcc/2002-07/msg01148.html) but PA64 will only
work at -O0 with that change, -O1/-O2/etc still fail with the
simplify_gen_subreg message.

Steve Ellcey
sje@cup.hp.com

Re: Vector modes under hppa64-hpu

[Aldy Hernandez]

> I don't know if building a cross ia64-hpux will work or not, but a pa64
> version should at least build cc1.  These two platforms are behaving
> slightly differently for me.  I can make IA64 work at all optimization
> levels with the change that I included in my earlier mail
> (http://gcc.gnu.org/ml/gcc/2002-07/msg01148.html) but PA64 will only
> work at -O0 with that change, -O1/-O2/etc still fail with the
> simplify_gen_subreg message.

flamingo:~/build/pa64/gcc$ cat a.c
typedef int v2si __attribute__ ((mode(V2SI)));
typedef unsigned di __attribute__ ((mode(DI)));
void foo(unsigned long);
void bar() {
            v2si x = { 1, 2 };
                foo((di) x);
}

flamingo:~/build/pa64/gcc$ ./cc1 a.c -O0 -quiet
flamingo:~/build/pa64/gcc$ ./cc1 a.c -O -quiet
flamingo:~/build/pa64/gcc$ ./cc1 a.c -O2 -quiet

no problem here.  --target=hppa64-linux

I tried --target=hppa64-hpux but configure dies with

*** Configuration hppa64-hp-hpux not supported
Configure in /home/aldyh/build/pa64/gcc failed, exiting.

If you can get me a cross target triplet combo that'll build me a
cross ./cc1... I'll [try to] fix your problem ;-).

Aldy

Re: Vector modes under hppa64-hpu

[John David Anglin]

> I tried --target=hppa64-hpux but configure dies with
> 
> *** Configuration hppa64-hp-hpux not supported
> Configure in /home/aldyh/build/pa64/gcc failed, exiting.
> 

Try --target=hppa64-hp-hpux11.00.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: Vector modes under hppa64-hpu

[Aldy Hernandez]

>>>>> "John" == John David Anglin <dave@hiauly1.hia.nrc.ca> writes:

 >> I tried --target=hppa64-hpux but configure dies with
 >> 
 >> *** Configuration hppa64-hp-hpux not supported
 >> Configure in /home/aldyh/build/pa64/gcc failed, exiting.
 >> 

 > Try --target=hppa64-hp-hpux11.00.

flamingo:~/build/pa64/gcc$ ./cc1 a.c -O2 -quiet
flamingo:~/build/pa64/gcc$ ./cc1 a.c -O1 -quiet
flamingo:~/build/pa64/gcc$ ./cc1 a.c -O -quiet
flamingo:~/build/pa64/gcc$ 

no problem here either.  This is with a checkout from cvs as of right
now.


Aldy

Re: Vector modes under hppa64-hpu

[John David Anglin]

> >>>>> "John" == John David Anglin <dave@hiauly1.hia.nrc.ca> writes:
> 
>  >> I tried --target=hppa64-hpux but configure dies with
>  >> 
>  >> *** Configuration hppa64-hp-hpux not supported
>  >> Configure in /home/aldyh/build/pa64/gcc failed, exiting.
>  >> 
> 
>  > Try --target=hppa64-hp-hpux11.00.
> 
> flamingo:~/build/pa64/gcc$ ./cc1 a.c -O2 -quiet
> flamingo:~/build/pa64/gcc$ ./cc1 a.c -O1 -quiet
> flamingo:~/build/pa64/gcc$ ./cc1 a.c -O -quiet
> flamingo:~/build/pa64/gcc$ 
> 
> no problem here either.  This is with a checkout from cvs as of right
> now.

With a checkout yesterday evening, I can confirm that simd-1.c no
longers fails on hppa64-hp-hpux11.00.  On the minus side, there are
a whole bunch on new regressions in other areas.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: Vector modes under hppa64-hpu

[Steve Ellcey]

> see optabs.c:expand_vector_binop()

Well, it doesn't look like expand_vector_binop or expand_vector_unop are
the problem because they are never used when compiling simd-1.c.  This
is because neither expand_binop or expand_unop are ever called.  I just
have a SET rtx and this isn't handled by expand_binop.

So, should there be some code in (or called by) expand_assignment that
handles transforming V2SI into a couple of SI's.

On PA64 I go to expand_assignment and I call store_expr and I don't see
any code to map V2SI to SI in either of these routines so the V2SI types
just percolate through until they cause an error during optimization.

  [hpsje - sje_simd] $ obj_pa64_gcc/gcc/cc1 -O1 x.c
   bar
  x.c: In function `bar':
  x.c:7: internal compiler error: Internal compiler error in simplify_gen_subreg, at simplify-rtx.c:2598


Steve Ellcey
sje@cup.hp.com

Re: Vector modes under hppa64-hpu

[Aldy Hernandez]

>   [hpsje - sje_simd] $ obj_pa64_gcc/gcc/cc1 -O1 x.c
>    bar
>   x.c: In function `bar':
>   x.c:7: internal compiler error: Internal compiler error in simplify_gen_subreg, at simplify-rtx.c:2598
> 

Can you post x.c so I can try to debug this?

Also, can I can make a cross ia64-hpux (or whatever) to reproduce your
error, as I don't have neither an ia64 nor a pa64.

Aldy

Re: Vector modes under hppa64-hpu

[Steve Ellcey]

Well, following up to my own mail, I have a couple of questions.  If I
am on a system that does not support the VECTOR modes, should I ever see
any rtx with a type of V2SImode?  I don't think I should, but I am not
sure.  When I run simd-1.c with -O0 on IA64 or PA64 I never see any code
with this mode.  When I run with -O1 I do see such code.  I believe that
this code is coming from store_constructor in expr.c.  With -O1, when
"TREE_CODE (type) == VECTOR_TYPE" I wind up setting need_to_clear to 1
because I am storing into a (64 bit) register, and that in turn winds up
calling emit_move_insn with a mode of V2SImode and I think that is wrong
since my platform does not support V2SImode.  With -O0, I do not store
into a register so store_constructor doesn't set need_to_clear and
everything works OK.

Steve Ellcey
sje@cup.hp.com

Re: Vector modes under hppa64-hpu

[Aldy Hernandez]

>>>>> "Steve" == Steve Ellcey <sje@cup.hp.com> writes:

 > Well, following up to my own mail, I have a couple of questions.  If I
 > am on a system that does not support the VECTOR modes, should I ever see
 > any rtx with a type of V2SImode?  I don't think I should, but I am
 > not

yes.  It should opencode the V2SI with a pair of SIs.

Aldy

Re: Vector modes under hppa64-hpu

[Steve Ellcey]

I was looking at simd-1.c on IA64 HP-UX and PA64 HP-UX and I think I
have a fix for simd-1.c that works on IA64 all the time and on PA64 *if*
I do not optimize.  To get rid of the problem in emit_move_insn I made
the change shown in the attached patch.  The problem is that the size of
V2SI is the same as UNITS_PER_WORD on a 64 bit machine so
emit_move_insn_1 didn't handle it with its slow method but it also had
no code to handle it directly before it got to this test.  On a 32 bit
machine this test would be true because V2SI is 8 bytes and
UNITS_PER_WORD is 4.  I modified the test to allow it to be true for
vectors even if the size is not greater then UNITS_PER_WORD.

Does this seem like a reasonable fix?  Or should there be code to handle
this somewhere else in emit_move_insn_1?  I think the generated code
would be correct, just slow, but that shouldn't matter if the platform
we are on doesn't support VECTOR modes anyway.

The problem I have with this patch, and the reason I haven't submitted
it to gcc-patches is that even with this patch PA64 fails to compile
simd-1.c at -O1 or higher optimizations.  I get the following message:

 [hpsje - sje_simd] $ obj_pa64_gcc/gcc/cc1 -O1 simd-1.c
  bar
 simd-1.c: In function `bar':
 simd-1.c:7: internal compiler error: Internal compiler error in simplify_gen_subreg, at simplify-rtx.c:2598
 Please submit a full bug report,
 with preprocessed source if appropriate.
 See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.

I haven't figured out what the problem is here.  Any ideas on what to be
looking for?  I wind up in simplify_gen_subreg with innermode == VOIDmode
and outermode == DImode.  op is "(clobber (const_int 0 [0x0]))" and
byte is 0.

Steve Ellcey
sje@cup.hp.com





*** expr.c@@/main/hp/LATEST     Wed Jul 10 13:06:24 2002
--- expr.c      Tue Jul 23 11:29:21 2002
*************** emit_move_insn_1 (x, y)
*** 3043,3049 ****
    /* This will handle any multi-word mode that lacks a move_insn pattern.
       However, you will get better code if you define such patterns,
       even if they must turn into multiple assembler instructions.  */
!   else if (GET_MODE_SIZE (mode) > UNITS_PER_WORD)
      {
        rtx last_insn = 0;
        rtx seq, inner;
--- 3043,3050 ----
    /* This will handle any multi-word mode that lacks a move_insn pattern.
       However, you will get better code if you define such patterns,
       even if they must turn into multiple assembler instructions.  */
!   else if ((VECTOR_MODE_P (mode) && !VECTOR_MODE_SUPPORTED_P (mode))
!           || GET_MODE_SIZE (mode) > UNITS_PER_WORD)
      {
        rtx last_insn = 0;
        rtx seq, inner;

Re: Vector modes under hppa64-hpu

[Aldy Hernandez]

>>>>> "John" == John David Anglin <dave@hiauly1.hia.nrc.ca> writes:

 > The gcc.c-torture/compile/simd-1.c test fails under hppa64-hp-hpux11.x
 > because emit_move_insn is called with the following:

 > (gdb) p debug_rtx (x)
 > (subreg:V2SI (reg:DI 69) 0)
 > $2 = void
 > (gdb) p debug_rtx (y)
 > (mem/f:V2SI (reg/f:DI 62 virtual-stack-vars) [0 x+0 S8 A64])

 > There is no support to move V2SI modes, so this causes an abort.
 > VECTOR_MODE_SUPPORTED_P is not defined for the target.

It doesn't matter if VECTOR_MODE_SUPPORTED_P is defined or not.  The
purpose of simd-1.c is to test gcc's ability to synthesize the V2SI
from a pair of SI's.

So the bug is in the inability to open code the simd instruction, or
in the subreg.  Could you do a little more investigating please?

Aldy