Re: [PATCH] Add VIS intrinsics header for sparc.

2011-09-26 Thread David Miller 
From: David Miller 
Date: Sat, 24 Sep 2011 17:30:57 -0400 (EDT)

> From: Hans-Peter Nilsson 
> Date: Sat, 24 Sep 2011 17:15:06 -0400 (EDT)
> 
>> One more: please consider adding a
>>  if (TARGET_VIS) builtin_define ("__VIS__=something") so I as a
>> user theoretically wouldn't *have* to autoconfiscate for the
>> changes. ;)
> 
> This is on my todo list as well, I'll try to emit some CPP define
> compatible with what Sun uses.  But, thanks for reminding me.

Hans, I just committed the following regstrapped patch to the trunk.


Move target CPP macro handling to C file and add __VIS/__VIS__.

* config/sparc/sparc-c.c: New file implementing sparc_target_macros,
which will now define __VIS and __VIS__ when -mvis is enabled.
* config/sparc/t-sparc: Likewise.
* config.gcc: Add sparc-c.o to c_target_objs and cxx_target_objs,
and add t-sparc to tmake_file for all sparc targets.
* config/sparc/sparc-protos.h (sparc_target_macros): Declare.
* config/sparc/sparc.h (TARGE_CPU_CPP_BUILTINS): Call it.
---
 gcc/ChangeLog   |   10 +++
 gcc/config.gcc  |   30 +-
 gcc/config/sparc/sparc-c.c  |   53 +++
 gcc/config/sparc/sparc-protos.h |1 +
 gcc/config/sparc/sparc.h|   20 +--
 gcc/config/sparc/t-sparc|   36 ++
 6 files changed, 119 insertions(+), 31 deletions(-)
 create mode 100644 gcc/config/sparc/sparc-c.c
 create mode 100644 gcc/config/sparc/t-sparc

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 71a8d88..309eca5 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,13 @@
+2011-09-26  David S. Miller  
+
+   * config/sparc/sparc-c.c: New file implementing sparc_target_macros,
+   which will now define __VIS and __VIS__ when -mvis is enabled.
+   * config/sparc/t-sparc: Likewise.
+   * config.gcc: Add sparc-c.o to c_target_objs and cxx_target_objs,
+   and add t-sparc to tmake_file for all sparc targets.
+   * config/sparc/sparc-protos.h (sparc_target_macros): Declare.
+   * config/sparc/sparc.h (TARGE_CPU_CPP_BUILTINS): Call it.
+
 2011-09-26  Georg-Johann Lay  
 
* config/avr/avr.md (peephole casesi+2): Use -1 instead of 65536.
diff --git a/gcc/config.gcc b/gcc/config.gcc
index 7183f26..cf11364 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -422,6 +422,8 @@ score*-*-*)
;;
 sparc*-*-*)
cpu_type=sparc
+   c_target_objs="sparc-c.o"
+   cxx_target_objs="sparc-c.o"
extra_headers="visintrin.h"
need_64bit_hwint=yes
;;
@@ -2457,32 +2459,32 @@ sparc-*-elf*)
tm_file="${tm_file} dbxelf.h elfos.h newlib-stdint.h sparc/sysv4.h 
sparc/sp-elf.h"
case ${target} in
*-leon-*)
-   tmake_file="sparc/t-leon"
+   tmake_file="sparc/t-sparc sparc/t-leon"
;;
*-leon[3-9]*)
-   tmake_file="sparc/t-leon3"
+   tmake_file="sparc/t-sparc sparc/t-leon3"
;;
*)
-   tmake_file="sparc/t-elf"
+   tmake_file="sparc/t-sparc sparc/t-elf"
;;
esac
;;
 sparc-*-rtems*)
tm_file="${tm_file} dbxelf.h elfos.h sparc/sysv4.h sparc/sp-elf.h 
sparc/rtemself.h rtems.h newlib-stdint.h"
-   tmake_file="sparc/t-elf t-rtems"
+   tmake_file="sparc/t-sparc sparc/t-elf t-rtems"
;;
 sparc-*-linux*)
tm_file="${tm_file} dbxelf.h elfos.h sparc/sysv4.h gnu-user.h linux.h 
glibc-stdint.h"
extra_options="${extra_options} sparc/long-double-switch.opt"
case ${target} in
*-leon-*)
-   tmake_file="${tmake_file} sparc/t-leon"
+   tmake_file="${tmake_file} sparc/t-sparc sparc/t-leon"
;;
*-leon[3-9]*)
-   tmake_file="${tmake_file} sparc/t-leon3"
+   tmake_file="${tmake_file} sparc/t-sparc sparc/t-leon3"
;;
*)
-   tmake_file="${tmake_file} sparc/t-linux"
+   tmake_file="${tmake_file} sparc/t-sparc sparc/t-linux"
;;
esac
if test x$enable_targets = xall; then
@@ -2497,6 +2499,7 @@ sparc-*-netbsdelf*)
tm_file="${tm_file} dbxelf.h elfos.h sparc/sysv4.h netbsd.h 
netbsd-elf.h sparc/netbsd-elf.h"
extra_options="${extra_options} netbsd.opt netbsd-elf.opt"
extra_options="${extra_options} sparc/long-double-switch.opt"
+   tmake_file="${tmake_file} sparc/t-sparc"
;;
 sparc*-*-solaris2*)
tm_file="sparc/biarch64.h ${tm_file} ${sol2_tm_file} sol2-bi.h"
@@ -2508,25 +2511,26 @@ sparc*-*-solaris2*)
test x$with_cpu != x || with_cpu=v9
;;
esac
-   tmake_file="${tmake_file} sparc/t-sol2-64"
+   tmake_file="${tmake_file} sparc/t-sparc sparc/t-sol2-64"
;;
 sparc-wrs-vxworks)
tm_file="${tm_fil

Re: [PATCH] Add VIS intrinsics header for sparc.

2011-09-25 Thread David Miller 
From: Gerald Pfeifer 
Date: Mon, 26 Sep 2011 00:50:22 +0200 (CEST)

> On Sun, 25 Sep 2011, David Miller wrote:
>> I'll add a note about this to gcc-4.7/changes.html along with
>> the FMAF stuff I'm about to commit.
> 
> Thanks for doing that, David.  I believe my automated tester has
> naged you over a small markup issue in the patch which I am 
> addressing thusly (together with some more markup).

Thanks a lot Gerald.

Re: [PATCH] Add VIS intrinsics header for sparc.

2011-09-25 Thread Gerald Pfeifer 
On Sun, 25 Sep 2011, David Miller wrote:
> I'll add a note about this to gcc-4.7/changes.html along with
> the FMAF stuff I'm about to commit.

Thanks for doing that, David.  I believe my automated tester has
naged you over a small markup issue in the patch which I am 
addressing thusly (together with some more markup).

Gerald

Index: changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.7/changes.html,v
retrieving revision 1.32
diff -u -r1.32 changes.html
--- changes.html25 Sep 2011 22:39:05 -  1.32
+++ changes.html25 Sep 2011 22:47:14 -
@@ -322,15 +322,16 @@
 operations.
 The compiler now properly tracks the %gsr register,
 and how it behaves as an input for various VIS instructions.
-Akin to 'fzero', the compiler can now generate 'fone' instructions
-in order to set all of the bits of a floating-point register to 
one.
+Akin to fzero, the compiler can now generate
+fone instructions in order to set all of the bits
+of a floating-point register to one.
 The documentation for the VIS intrinsics in the GCC manual has
 been brought up to date and many inaccuracies were fixed.
   
 
-Support for UltraSPARC Fused Multiply-Add Floating-point
+Support for UltraSPARC Fused Multiply-Add floating-point
 extensions has been added.  These instructions are enabled by
-default on UltraSPARC T3 (Niagara 3) and later cpus.
+default on UltraSPARC T3 (Niagara 3) and later CPUs.
   
 
 picochip
>

Re: [PATCH] Add VIS intrinsics header for sparc.

2011-09-25 Thread Hans-Peter Nilsson 
On Sun, 25 Sep 2011, David Miller wrote:
> For some reason I can't take ownership of your PR and mark it
> closed, otherwise I'd do so as well.

Done, thanks.  The most common cause is not using your
gcc.gnu.org account in bugzilla, needed to get those
superpowers.  (For future reference, marking the ChangeLog with
the PR is helpful too.)  BTW, no test-cases.

brgds, H-P

Re: [PATCH] Add VIS intrinsics header for sparc.

2011-09-25 Thread David Miller 
From: David Miller 
Date: Sun, 25 Sep 2011 00:45:59 -0400 (EDT)

> From: David Miller 
> Date: Sat, 24 Sep 2011 02:08:32 -0400 (EDT)
> 
>> I'll look into your other suggestion in PR48974, namely making use of
>> fone VIS instructions.
> 
> Hans, just FYI, here is a patch I am regression testing which
> implements this.

It passed and I committed it to trunk.

For some reason I can't take ownership of your PR and mark it
closed, otherwise I'd do so as well.

I'll add a note about this to gcc-4.7/changes.html along with
the FMAF stuff I'm about to commit.

Re: [PATCH] Add VIS intrinsics header for sparc.

2011-09-24 Thread David Miller 
From: David Miller 
Date: Sat, 24 Sep 2011 02:08:32 -0400 (EDT)

> I'll look into your other suggestion in PR48974, namely making use of
> fone VIS instructions.

Hans, just FYI, here is a patch I am regression testing which
implements this.

diff --git a/gcc/config/sparc/constraints.md b/gcc/config/sparc/constraints.md
index cca34ed..317602c 100644
--- a/gcc/config/sparc/constraints.md
+++ b/gcc/config/sparc/constraints.md
@@ -18,7 +18,7 @@
 ;; .
 
 ;;; Unused letters:
-;;;ABCD   P Z
+;;;AB   
 ;;;ajklq  tuvwxyz
 
 
@@ -52,6 +52,10 @@
  (and (match_code "const_double")
   (match_test "const_zero_operand (op, mode)")))
 
+(define_constraint "C"
+ "The floating-point all-ones constant"
+ (and (match_code "const_double")
+  (match_test "const_all_ones_operand (op, mode)")))
 
 ;; Integer constant constraints
 
@@ -95,6 +99,10 @@
  (and (match_code "const_int")
   (match_test "ival == 4096")))
 
+(define_constraint "P"
+ "The integer constant -1"
+ (and (match_code "const_int")
+  (match_test "ival == -1")))
 
 ;; Extra constraints
 ;; Our memory extra constraints have to emulate the behavior of 'm' and 'o',
@@ -146,3 +154,8 @@
  "The vector zero constant"
  (and (match_code "const_vector")
   (match_test "const_zero_operand (op, mode)")))
+
+(define_constraint "Z"
+ "The vector all ones constant"
+ (and (match_code "const_vector")
+  (match_test "const_all_ones_operand (op, mode)")))
diff --git a/gcc/config/sparc/predicates.md b/gcc/config/sparc/predicates.md
index 4af960a..21399b5 100644
--- a/gcc/config/sparc/predicates.md
+++ b/gcc/config/sparc/predicates.md
@@ -29,6 +29,35 @@
   (and (match_code "const_int,const_double,const_vector")
(match_test "op == CONST1_RTX (mode)")))
 
+;; Return true if the integer representation of OP is
+;; all-ones.
+(define_predicate "const_all_ones_operand"
+  (match_code "const_int,const_double,const_vector")
+{
+  if (GET_CODE (op) == CONST_INT && INTVAL (op) == -1)
+return true;
+#if HOST_BITS_PER_WIDE_INT == 32
+  if (GET_CODE (op) == CONST_DOUBLE
+  && GET_MODE (op) == VOIDmode
+  && CONST_DOUBLE_HIGH (op) == ~(HOST_WIDE_INT)0
+  && CONST_DOUBLE_LOW (op) == ~(HOST_WIDE_INT)0)
+return true;
+#endif
+  if (GET_CODE (op) == CONST_VECTOR)
+{
+  int i, num_elem = CONST_VECTOR_NUNITS (op);
+
+  for (i = 0; i < num_elem; i++)
+{
+  rtx n = CONST_VECTOR_ELT (op, i);
+  if (! const_all_ones_operand (n, mode))
+return false;
+}
+  return true;
+}
+  return false;
+})
+
 ;; Return true if OP is the integer constant 4096.
 (define_predicate "const_4096_operand"
   (and (match_code "const_int")
@@ -211,6 +240,12 @@
   (ior (match_operand 0 "register_operand")
(match_operand 0 "const_zero_operand")))
 
+;; Return true if OP is either the zero constant, the all-ones
+;; constant, or a register.
+(define_predicate "register_or_zero_or_all_ones_operand"
+  (ior (match_operand 0 "register_or_zero_operand")
+   (match_operand 0 "const_all_ones_operand")))
+
 ;; Return true if OP is a register operand in a floating point register.
 (define_predicate "fp_register_operand"
   (match_operand 0 "register_operand")
diff --git a/gcc/config/sparc/sparc.c b/gcc/config/sparc/sparc.c
index d648e87..3446379 100644
--- a/gcc/config/sparc/sparc.c
+++ b/gcc/config/sparc/sparc.c
@@ -1170,9 +1170,11 @@ sparc_expand_move (enum machine_mode mode, rtx *operands)
   if (operands [1] == const0_rtx)
operands[1] = CONST0_RTX (mode);
 
-  /* We can clear FP registers if TARGET_VIS, and always other regs.  */
+  /* We can clear or set to all-ones FP registers if TARGET_VIS, and
+always other regs.  */
   if ((TARGET_VIS || REGNO (operands[0]) < SPARC_FIRST_FP_REG)
- && const_zero_operand (operands[1], mode))
+ && (const_zero_operand (operands[1], mode)
+ || const_all_ones_operand (operands[1], mode)))
return false;
 
   if (REGNO (operands[0]) < SPARC_FIRST_FP_REG
@@ -3096,19 +3098,21 @@ sparc_legitimate_constant_p (enum machine_mode mode, 
rtx x)
 return true;
 
   /* Floating point constants are generally not ok.
-The only exception is 0.0 in VIS.  */
+The only exception is 0.0 and all-ones in VIS.  */
   if (TARGET_VIS
  && SCALAR_FLOAT_MODE_P (mode)
- && const_zero_operand (x, mode))
+ && (const_zero_operand (x, mode)
+ || const_all_ones_operand (x, mode)))
return true;
 
   return false;
 
 case CONST_VECTOR:
   /* Vector constants are generally not ok.
-The only exception is 0 in VIS.  */
+The only exception is 0 or -1 in VIS.  */
   if (TARGET_VIS
- && const_zero_operand (x, mode))
+ && (const_zero_operand (x, mode)
+ || const_all_ones_operand (x, mode)))
return true;
 
   retu

Re: [PATCH] Add VIS intrinsics header for sparc.

2011-09-24 Thread David Miller 
From: David Miller 
Date: Sat, 24 Sep 2011 20:05:19 -0400 (EDT)

> From: Hans-Peter Nilsson 
> Date: Sat, 24 Sep 2011 19:32:55 -0400 (EDT)
> 
>> PS. gcc-4.7/changes.html?
> 
> Also on my TODO list, and Eric made some noise about documenting these
> improvements as well, thanks for the reminder.

I just commited an update to the wwwdocs.

Re: [PATCH] Add VIS intrinsics header for sparc.

2011-09-24 Thread David Miller 
From: Hans-Peter Nilsson 
Date: Sat, 24 Sep 2011 19:32:55 -0400 (EDT)

> PS. gcc-4.7/changes.html?

Also on my TODO list, and Eric made some noise about documenting these
improvements as well, thanks for the reminder.

I'll post and commit the current version of my %gsr changes after my
bootstrap/testsuite run finishes.

Re: [PATCH] Add VIS intrinsics header for sparc.

2011-09-24 Thread Hans-Peter Nilsson 
On Sat, 24 Sep 2011, David Miller wrote:

> From: Hans-Peter Nilsson 
> Date: Sat, 24 Sep 2011 18:37:33 -0400 (EDT)
>
> > BTW, don't forget to clobber GSR at call insns!
>
> This I explicitly want to avoid and is an explicit design decision.

Aha, now I get it; that's certainly key.  Thanks for taking the time.

Yes, it's certainly more flexible to have the user set GSR than
allowing gcc to clobber it when seeing VIS intrinsics, at the
minor usability cost of the user having to keep track of GSR
separately to when used in the individual intrinsics.

> Like I said the model is like setting the floating point rounding mode
> for a family of functions.

Aha 2: I didn't interpret what you wrote as referring to the
model; I thought you meant the actual function (one of the
usages of the fpack insns being "fixed math").  Sure.

> Zero is equivalent to "don't care" in this situation if either
> 1) you aren't doing any falignaddr operations or 2) you are

(JFTR, "faligndata")

> then going to subsequently do an "alignaddr" to set that field
> up.

brgds, H-P
PS. gcc-4.7/changes.html?

Re: [PATCH] Add VIS intrinsics header for sparc.

2011-09-24 Thread David Miller 
From: Hans-Peter Nilsson 
Date: Sat, 24 Sep 2011 18:37:33 -0400 (EDT)

> BTW, don't forget to clobber GSR at call insns!

This I explicitly want to avoid and is an explicit design decision.

Like I said the model is like setting the floating point rounding mode
for a family of functions.

You set the floating point rounding mode at the top level, run your
kernel and all the helper functions in that mode.

The %gsr scaling factor is to be used similarly.

You have to control all the functions that get called once you set the
%gsr before a calculation, and they either have to explicitly save and
restore the %gsr around changes to %gsr, or have been designed to use
the %gsr setting made by the callee.

The last thing I want to do is have to teach reload how to handle this
thing, it simply makes no sense to put that much engineering into it
if it is for zero or very little gain.

And it would explicitly prevent the kind of model I see as the most
reasonable for using this register, in that if we clobber it during
a call there is no way for the user to say not to save and restore
%gsr over a call.

>> So on the first set I'd have to read it, mask it out, then set the
>> scale bits.  A needless waste of 20 to 30 cycles on UltraSPARC-III.
> 
> No, it doesn't have to be read.  If the fields have (useful)
> implicit initial values (like scale=7 and align=4) at the
> beginning of any function, you wouldn't have to read and mask,
> just set.

You can't just set.  What about the VIS-2.0 byte-mask at the top
32-bits of the register, are you just going to clobber that when you
change the scale factor?

If we support treating the different fields as different registers we
have to preserve the setting of the other fields of %gsr when we
change one of them.  There are 5 fields currently defined:

1) align address <2:0>
2) scale factor <7:3>
3) interval rounding mode (VIS 2.0) <26:25>
4) interval mode enable <27>
5) Byte mask (VIS 2.0) <63:32>

And also this idea of using get_hard_reg_initial_val() to "optimize"
this kind of usage especially forces us to clobber the %gsr over
function calls which, as stated, I want to avoid if at all possible.

>> Again, this doesn't allow the user to say "don't care" about the other
>> fields like a plain "__vis_write_gsr(2<<3)" call does.
> 
> But that'd set GSR.alignaddr_offset to 0 rather than "don't
> care".

Zero is equivalent to "don't care" in this situation if either
1) you aren't doing any falignaddr operations or 2) you are
then going to subsequently do an "alignaddr" to set that field
up.

Look at the medialib code, that's basically the usage model there
and I think it's quite reasonable.

> It doesn't add hurdles for a revisit, if the mechanism is found
> unusable or the generated code pessimal!

Absolutely, thanks for your review.

Re: [PATCH] Add VIS intrinsics header for sparc.

2011-09-24 Thread Hans-Peter Nilsson 
On Sat, 24 Sep 2011, David Miller wrote:
> From: Hans-Peter Nilsson 
> Date: Sat, 24 Sep 2011 17:15:06 -0400 (EDT)
> > I'd prefer it as a parameter to the builtins (expanding to two
> > insns, letting gcc get rid of the redundant ones; let the
> > initialization value be 0).  I understand you're trying to keep
> > some kind of compatibility there, but additional builtins would
> > do the trick and fit nicely: the new builtins expanding to a set
> > of GSR (GSR field) followed by the "old" insn but fixed as in
> > this patch.  Besides, the functions that use GSR still can't be
> > const in this patch.  I guess they never can, when you think of
> > it, setting and/or using a register that can affect/be affected
> > something elsewhere, when that something is known to gcc.  Oh well.
>
> I read this idea in your PR before I did this work and I disagree that
> this is a better approach, because then I have to assume that you care
> about all the other bits in the %gsr register.

I don't understand what you mean here.  Maybe it doesn't
matter...  My suggestions come from observing what gcc did to
the "faked gsr modelling" I had to use with the current releases
(what moving and eliminating redundant variable settings used in
asms that it did; turned out acceptable FWIW, no redundant
reads), which would map directly to my suggestion.  But I guess
you have a point in that your setting-gsr-then-using-builtins
maps better to the machine insns.

BTW, don't forget to clobber GSR at call insns!

> So on the first set I'd have to read it, mask it out, then set the
> scale bits.  A needless waste of 20 to 30 cycles on UltraSPARC-III.

No, it doesn't have to be read.  If the fields have (useful)
implicit initial values (like scale=7 and align=4) at the
beginning of any function, you wouldn't have to read and mask,
just set.  (Caveat: the port has to have a way to emit a
gsr-setting even if the supposed-initial-values are specified -
like another register or variable, or the initial-value
machinery as I suggested.)

> If you just call "__vis_write_gsr()" at the beginning of your kernel,
> you can tell the compiler that you just want to set the scaling bits
> and you don't care about the others at all.

Don't care how?  They're certainly set by both __vis_write_gsr()
and alignaddr and used by faligndata.  I guess my confusion is
that I don't see what aspect is "don't care" here that'd be
"care" with my suggestion.

> > Another aspect would be to model the different GSR fields as
> > different registers; they're used completely differently and
> > just happen to be set with the same insn.  That might help gcc
> > getting rid of redundant settings.
>
> Again, this doesn't allow the user to say "don't care" about the other
> fields like a plain "__vis_write_gsr(2<<3)" call does.

But that'd set GSR.alignaddr_offset to 0 rather than "don't
care".

> You know what fields actually matter for your code.

A good reason to model them as different registers!

Still, this is a good start and much more workable (and
schedulable) than what's already there, thank you for that.
It doesn't add hurdles for a revisit, if the mechanism is found
unusable or the generated code pessimal!

brgds, H-P

Re: [PATCH] Add VIS intrinsics header for sparc.

2011-09-24 Thread David Miller 
From: Hans-Peter Nilsson 
Date: Sat, 24 Sep 2011 17:15:06 -0400 (EDT)

> It's more of a parameter actually, GSR.scale_factor is the
> bit-shift count for the pack insns and GSR.alignaddr_offset the
> byte-shift in the aligndata insns.

I realize this.

> I'd prefer it as a parameter to the builtins (expanding to two
> insns, letting gcc get rid of the redundant ones; let the
> initialization value be 0).  I understand you're trying to keep
> some kind of compatibility there, but additional builtins would
> do the trick and fit nicely: the new builtins expanding to a set
> of GSR (GSR field) followed by the "old" insn but fixed as in
> this patch.  Besides, the functions that use GSR still can't be
> const in this patch.  I guess they never can, when you think of
> it, setting and/or using a register that can affect/be affected
> something elsewhere, when that something is known to gcc.  Oh well.

I read this idea in your PR before I did this work and I disagree that
this is a better approach, because then I have to assume that you care
about all the other bits in the %gsr register.

So on the first set I'd have to read it, mask it out, then set the
scale bits.  A needless waste of 20 to 30 cycles on UltraSPARC-III.

If you just call "__vis_write_gsr()" at the beginning of your kernel,
you can tell the compiler that you just want to set the scaling bits
and you don't care about the others at all.

> Another aspect would be to model the different GSR fields as
> different registers; they're used completely differently and
> just happen to be set with the same insn.  That might help gcc
> getting rid of redundant settings.

Again, this doesn't allow the user to say "don't care" about the other
fields like a plain "__vis_write_gsr(2<<3)" call does.

You know what fields actually matter for your code.

> FWIW not "need"; IIUC at least faligndata *can* be a vec_select
> of a vec_concat of the two vectors, but in practice I don't
> think gcc can make use of it yet and all ports use unspec...
> 
> While on faligndata, see vec_realign_load_ (sadly
> undocumented at present); it'll enable the autovectorizer to...
> autovectorize some more.  (Right, I'm working on [yet] another
> SIMD back-end, implemented as MIPS COP2 insns.)

Thanks for these suggestions.

> How about putting it inside the unspec vector?  Those "use"
> thingies always gives me the creeps; outside of an insn (no, not
> here) they're sometimes lost and at least disconnected to the
> insn.  I think practically there's no difference here.

The canonical thing to do is to put them outside of the unspec
so that is what I have done.

> One more: please consider adding a
>  if (TARGET_VIS) builtin_define ("__VIS__=something") so I as a
> user theoretically wouldn't *have* to autoconfiscate for the
> changes. ;)

This is on my todo list as well, I'll try to emit some CPP define
compatible with what Sun uses.  But, thanks for reminding me.

>> +  def_builtin_const ("__builtin_vis_fpack16", CODE_FOR_fpack16_vis,
>> + v4qi_ftype_v4hi);
>> +  def_builtin_const ("__builtin_vis_fpack32", CODE_FOR_fpack32_vis,
>> + v8qi_ftype_v2si_v8qi);
>> +  def_builtin_const ("__builtin_vis_fpackfix", CODE_FOR_fpackfix_vis,
>> + v2hi_ftype_v2si);
>>def_builtin_const ("__builtin_vis_fexpand", CODE_FOR_fexpand_vis,
>>   v4hi_ftype_v4qi);
> 
> No, they (and aligndata) can't be const as long as they're
> affected by something other than their parameters (GSR); pure
> yes but not const.  See extend.texi.

Good catch, I was thinking purely on the RTL level where we do show
the compiler all of the "inputs" but at the tree level this is not
visible.

I'll fix that up for the next revision.

>> +  def_builtin_const ("__builtin_vis_alignaddr", 
>> CODE_FOR_alignaddrdi_vis,
>> + ptr_ftype_ptr_di);
>> +  def_builtin_const ("__builtin_vis_alignaddrl", 
>> CODE_FOR_alignaddrldi_vis,
>> + ptr_ftype_ptr_di);
> 
> Can't be neither pure nor const; affects something global (GSR).

Gotcha.

I'd like to revisit this at some point in the future though, maybe we
can legitimately at least mark these things pure.

Re: [PATCH] Add VIS intrinsics header for sparc.

2011-09-24 Thread Hans-Peter Nilsson 
On Sat, 24 Sep 2011, David Miller wrote:
> Hans, here is what I'm playing with right now against current
> trunk.

A spot-check review:

> I looked at the use cases for making use of the scale factor in the
> VIS %gsr register and it's used similar to how rounding modes are
> modified in the FPU control register.

It's more of a parameter actually, GSR.scale_factor is the
bit-shift count for the pack insns and GSR.alignaddr_offset the
byte-shift in the aligndata insns.

> You have a function, or family of functions, that want to operate with
> a certain scale factor.  And at the top level the first thing you do
> is set the %gsr as you want it to be set.

Certainly an improvement, but...

> So I've added a GSR register to the sparc backend and then added
> __vis_write_gsr() and __vis_read_gsr() functions to facilitate the
> use cases I've seen.

I'd prefer it as a parameter to the builtins (expanding to two
insns, letting gcc get rid of the redundant ones; let the
initialization value be 0).  I understand you're trying to keep
some kind of compatibility there, but additional builtins would
do the trick and fit nicely: the new builtins expanding to a set
of GSR (GSR field) followed by the "old" insn but fixed as in
this patch.  Besides, the functions that use GSR still can't be
const in this patch.  I guess they never can, when you think of
it, setting and/or using a register that can affect/be affected
something elsewhere, when that something is known to gcc.  Oh well.

Another aspect would be to model the different GSR fields as
different registers; they're used completely differently and
just happen to be set with the same insn.  That might help gcc
getting rid of redundant settings.

> This allowed me to describe to the compiler exactly what the alignaddr
> instructions do, and thus the unspecs for them are now gone.
>
> The pack and faligndata intrinsics still need to be unspec,

FWIW not "need"; IIUC at least faligndata *can* be a vec_select
of a vec_concat of the two vectors, but in practice I don't
think gcc can make use of it yet and all ports use unspec...

While on faligndata, see vec_realign_load_ (sadly
undocumented at present); it'll enable the autovectorizer to...
autovectorize some more.  (Right, I'm working on [yet] another
SIMD back-end, implemented as MIPS COP2 insns.)

> and thus I
> merely added GSR uses to those patterns which is enough to let the
> compiler get the dataflow right.

How about putting it inside the unspec vector?  Those "use"
thingies always gives me the creeps; outside of an insn (no, not
here) they're sometimes lost and at least disconnected to the
insn.  I think practically there's no difference here.

> This all seems sufficient for what things like Sun's medialib and your
> RAPP project want to do.
>
> I'll look into your other suggestion in PR48974, namely making use of
> fone VIS instructions.

One more: please consider adding a
 if (TARGET_VIS) builtin_define ("__VIS__=something") so I as a
user theoretically wouldn't *have* to autoconfiscate for the
changes. ;)

> +  def_builtin_const ("__builtin_vis_fpack16", CODE_FOR_fpack16_vis,
> +  v4qi_ftype_v4hi);
> +  def_builtin_const ("__builtin_vis_fpack32", CODE_FOR_fpack32_vis,
> +  v8qi_ftype_v2si_v8qi);
> +  def_builtin_const ("__builtin_vis_fpackfix", CODE_FOR_fpackfix_vis,
> +  v2hi_ftype_v2si);
>def_builtin_const ("__builtin_vis_fexpand", CODE_FOR_fexpand_vis,
>v4hi_ftype_v4qi);

No, they (and aligndata) can't be const as long as they're
affected by something other than their parameters (GSR); pure
yes but not const.  See extend.texi.


> +  def_builtin_const ("__builtin_vis_alignaddr", CODE_FOR_alignaddrdi_vis,
> +  ptr_ftype_ptr_di);
> +  def_builtin_const ("__builtin_vis_alignaddrl", 
> CODE_FOR_alignaddrldi_vis,
> +  ptr_ftype_ptr_di);

Can't be neither pure nor const; affects something global (GSR).

BTW, vector header files are overrated, at least when there's no
compiler compatibility expected.  They can even be in the way:
there's an ARM NEON PR being stalled because of concern that the
header could be used with another gcc version.  Bah. ...ok I see
visintrin.h is already in.  Never mind then. :)

brgds, H-P

Re: [PATCH] Add VIS intrinsics header for sparc.

2011-09-23 Thread David Miller 

Hans, here is what I'm playing with right now against current
trunk.

I looked at the use cases for making use of the scale factor in the
VIS %gsr register and it's used similar to how rounding modes are
modified in the FPU control register.

You have a function, or family of functions, that want to operate with
a certain scale factor.  And at the top level the first thing you do
is set the %gsr as you want it to be set.

So I've added a GSR register to the sparc backend and then added
__vis_write_gsr() and __vis_read_gsr() functions to facilitate the
use cases I've seen.

This allowed me to describe to the compiler exactly what the alignaddr
instructions do, and thus the unspecs for them are now gone.

The pack and faligndata intrinsics still need to be unspec, and thus I
merely added GSR uses to those patterns which is enough to let the
compiler get the dataflow right.

This all seems sufficient for what things like Sun's medialib and your
RAPP project want to do.

I'll look into your other suggestion in PR48974, namely making use of
fone VIS instructions.

Thanks.

diff --git a/gcc/config/sparc/sparc.c b/gcc/config/sparc/sparc.c
index d62d5a1..f38ecda 100644
--- a/gcc/config/sparc/sparc.c
+++ b/gcc/config/sparc/sparc.c
@@ -329,7 +329,7 @@ char leaf_reg_remap[] =
   72, 73, 74, 75, 76, 77, 78, 79,
   80, 81, 82, 83, 84, 85, 86, 87,
   88, 89, 90, 91, 92, 93, 94, 95,
-  96, 97, 98, 99, 100};
+  96, 97, 98, 99, 100, 101, 102};
 
 /* Vector, indexed by hard register number, which contains 1
for a register that is allowable in a candidate for leaf
@@ -347,7 +347,7 @@ char sparc_leaf_regs[] =
   1, 1, 1, 1, 1, 1, 1, 1,
   1, 1, 1, 1, 1, 1, 1, 1,
   1, 1, 1, 1, 1, 1, 1, 1,
-  1, 1, 1, 1, 1};
+  1, 1, 1, 1, 1, 1, 1};
 
 struct GTY(()) machine_function
 {
@@ -4036,8 +4036,8 @@ static const int hard_32bit_mode_classes[] = {
   /* %fcc[0123] */
   CCFP_MODES, CCFP_MODES, CCFP_MODES, CCFP_MODES,
 
-  /* %icc */
-  CC_MODES
+  /* %icc, %sfp, %gsr */
+  CC_MODES, 0, S_MODES
 };
 
 static const int hard_64bit_mode_classes[] = {
@@ -4061,8 +4061,8 @@ static const int hard_64bit_mode_classes[] = {
   /* %fcc[0123] */
   CCFP_MODES, CCFP_MODES, CCFP_MODES, CCFP_MODES,
 
-  /* %icc */
-  CC_MODES
+  /* %icc, %sfp, %gsr */
+  CC_MODES, 0, S_MODES
 };
 
 int sparc_mode_class [NUM_MACHINE_MODES];
@@ -9168,14 +9168,18 @@ sparc_vis_init_builtins (void)
  v4hi, v4hi, 0);
   tree si_ftype_v2si_v2si = build_function_type_list (intSI_type_node,
  v2si, v2si, 0);
+  tree void_ftype_si = build_function_type_list (void_type_node,
+intSI_type_node, 0);
+  tree si_ftype_void = build_function_type_list (intSI_type_node,
+void_type_node, 0);
 
   /* Packing and expanding vectors.  */
-  def_builtin ("__builtin_vis_fpack16", CODE_FOR_fpack16_vis,
-  v4qi_ftype_v4hi);
-  def_builtin ("__builtin_vis_fpack32", CODE_FOR_fpack32_vis,
-  v8qi_ftype_v2si_v8qi);
-  def_builtin ("__builtin_vis_fpackfix", CODE_FOR_fpackfix_vis,
-  v2hi_ftype_v2si);
+  def_builtin_const ("__builtin_vis_fpack16", CODE_FOR_fpack16_vis,
+v4qi_ftype_v4hi);
+  def_builtin_const ("__builtin_vis_fpack32", CODE_FOR_fpack32_vis,
+v8qi_ftype_v2si_v8qi);
+  def_builtin_const ("__builtin_vis_fpackfix", CODE_FOR_fpackfix_vis,
+v2hi_ftype_v2si);
   def_builtin_const ("__builtin_vis_fexpand", CODE_FOR_fexpand_vis,
 v4hi_ftype_v4qi);
   def_builtin_const ("__builtin_vis_fpmerge", CODE_FOR_fpmerge_vis,
@@ -9198,27 +9202,33 @@ sparc_vis_init_builtins (void)
 v2si_ftype_v4qi_v2hi);
 
   /* Data aligning.  */
-  def_builtin ("__builtin_vis_faligndatav4hi", CODE_FOR_faligndatav4hi_vis,
-  v4hi_ftype_v4hi_v4hi);
-  def_builtin ("__builtin_vis_faligndatav8qi", CODE_FOR_faligndatav8qi_vis,
-  v8qi_ftype_v8qi_v8qi);
-  def_builtin ("__builtin_vis_faligndatav2si", CODE_FOR_faligndatav2si_vis,
-  v2si_ftype_v2si_v2si);
-  def_builtin ("__builtin_vis_faligndatadi", CODE_FOR_faligndatadi_vis,
-  di_ftype_di_di);
+  def_builtin_const ("__builtin_vis_faligndatav4hi", 
CODE_FOR_faligndatav4hi_vis,
+v4hi_ftype_v4hi_v4hi);
+  def_builtin_const ("__builtin_vis_faligndatav8qi", 
CODE_FOR_faligndatav8qi_vis,
+v8qi_ftype_v8qi_v8qi);
+  def_builtin_const ("__builtin_vis_faligndatav2si", 
CODE_FOR_faligndatav2si_vis,
+v2si_ftype_v2si_v2si);
+  def_builtin_const ("__builtin_vis_faligndatadi", CODE_FOR_faligndatadi_vis,
+di_ftype_di_di);
+
+  def_builtin ("__builtin_vis_write_gsr", CODE_FOR_wrgsr_vis,
+  void_ftype_si);
+  def_builtin ("__builtin_vis_read_gsr", CODE_FOR_rdgsr_vis,
+  si_ftype_void);
+
   if (TARGET_ARCH64)

Re: [PATCH] Add VIS intrinsics header for sparc.

2011-09-22 Thread Hans-Peter Nilsson 
On Thu, 22 Sep 2011, David Miller wrote:
> Positive feedback for the fact that someone is at least working on
> this stuff at all would be appreciated as well.

Using it or working on it?  Not that much of either, sorry, but
what I found when using it, I put in PR48974 (well, besides the
ICE's, which got separate PR's, of which Eric's been fixing some).

(For VIS, why not make use of fone / fones!)

brgds, H-P

Re: [PATCH] Add VIS intrinsics header for sparc.

2011-09-21 Thread David Miller 
From: Hans-Peter Nilsson 
Date: Wed, 21 Sep 2011 23:27:38 -0400 (EDT)

> Minor inconsistency spotted there: the same goes for the fpack
> insns but you now set TREE_READONLY for them.  (Not claiming I
> caught all of them.)

Thanks a lot for pointing this out, I'll remove the TREE_READONLY flag
for these operations.

Positive feedback for the fact that someone is at least working on
this stuff at all would be appreciated as well.

Re: [PATCH] Add VIS intrinsics header for sparc.

2011-09-21 Thread Hans-Peter Nilsson 
On Wed, 21 Sep 2011, David Miller wrote:
> From: Hans-Peter Nilsson 
> Date: Wed, 21 Sep 2011 21:27:08 -0400 (EDT)
>
> > While revisiting VIS, *please* consider fixing a big usability
> > problem: the pack and aligndata builtins don't take GSR in
> > account; it has unknown state and might be changed as a
> > side-effect of a previous VIS insn (well, alignaddr).  The
> > affected builtins don't have dependencies to GSR or a means to
> > set it besides in an asm; hardly usable at all.  See PR48974.
>
> I know, see my posting from yesterday:
>
> 
> Subject: [PATCH] Use TREE_READONLY on some sparc VIS builtins
>
> While fiddling around with the VIS intrinsic builtins I noticed that
> none of them have TREE_READONLY set, so the resulting code can be
> terrible.
>
> We can't currently do this for alignaddr and faligndata because we
> don't model the way those instructions use the %gsr register.

Minor inconsistency spotted there: the same goes for the fpack
insns but you now set TREE_READONLY for them.  (Not claiming I
caught all of them.)

brgds, H-P

Re: [PATCH] Add VIS intrinsics header for sparc.

2011-09-21 Thread David Miller 
From: Hans-Peter Nilsson 
Date: Wed, 21 Sep 2011 21:27:08 -0400 (EDT)

> While revisiting VIS, *please* consider fixing a big usability
> problem: the pack and aligndata builtins don't take GSR in
> account; it has unknown state and might be changed as a
> side-effect of a previous VIS insn (well, alignaddr).  The
> affected builtins don't have dependencies to GSR or a means to
> set it besides in an asm; hardly usable at all.  See PR48974.

I know, see my posting from yesterday:


Subject: [PATCH] Use TREE_READONLY on some sparc VIS builtins

While fiddling around with the VIS intrinsic builtins I noticed that
none of them have TREE_READONLY set, so the resulting code can be
terrible.

We can't currently do this for alignaddr and faligndata because we
don't model the way those instructions use the %gsr register.

Re: [PATCH] Add VIS intrinsics header for sparc.

2011-09-21 Thread Hans-Peter Nilsson 
On Fri, 16 Sep 2011, David Miller wrote:
>
> I've been meaning to toss something like this together for a while.
>
> If we were going to do this, I wanted to get it out of the way before
> adding VIS2 and VIS3 support.

While revisiting VIS, *please* consider fixing a big usability
problem: the pack and aligndata builtins don't take GSR in
account; it has unknown state and might be changed as a
side-effect of a previous VIS insn (well, alignaddr).  The
affected builtins don't have dependencies to GSR or a means to
set it besides in an asm; hardly usable at all.  See PR48974.

brgds, H-P

Re: [PATCH] Add VIS intrinsics header for sparc.

2011-09-16 Thread David Miller 
From: Eric Botcazou 
Date: Fri, 16 Sep 2011 23:01:56 +0200

>> Eric, any objections?
> 
> None, this looks OK to me.

Thanks Eric, I'll check this in.

Re: [PATCH] Add VIS intrinsics header for sparc.

2011-09-16 Thread Eric Botcazou 
> I considered trying to make a set of VIS headers compatible with the
> vis_*.h headers Sun provides in medialib and Sun Studio, but that's
> not possible since we use fundamentally different types in the
> builtins provided by GCC.
>
> Sun uses "double" and "float" in the declarations whereas we use our
> vector types.
>
> I even checked various users of Sun's VIS intrinsics and they all just
> declare their vector variables as "float" and "double" so it would be
> impossible to provide headers that would work out of the box.

Yes, I have some recollections of that.

> Eric, any objections?

None, this looks OK to me.

-- 
Eric Botcazou

Re: [PATCH] Add VIS intrinsics header for sparc.

2011-09-16 Thread David Miller 
From: Jakub Jelinek 
Date: Fri, 16 Sep 2011 21:07:09 +0200

> On Fri, Sep 16, 2011 at 03:02:07PM -0400, David Miller wrote:
>> +extern __inline void *
>> +__attribute__ ((__gnu_inline__, __always_inline__, __artificial__))
>> +__vis_alignaddr (void *__A, long __B)
>> +{
>> +return __builtin_vis_alignaddr(__A, __B);
> 
> Just formatting nits, two spaces instead of tab to indent and
> space in between function name and (.

Thanks Jakub, I'll fix those up.

Re: [PATCH] Add VIS intrinsics header for sparc.

2011-09-16 Thread Jakub Jelinek 
On Fri, Sep 16, 2011 at 03:02:07PM -0400, David Miller wrote:
> +extern __inline void *
> +__attribute__ ((__gnu_inline__, __always_inline__, __artificial__))
> +__vis_alignaddr (void *__A, long __B)
> +{
> + return __builtin_vis_alignaddr(__A, __B);

Just formatting nits, two spaces instead of tab to indent and
space in between function name and (.

Jakub