Add VIS intrinsics header for sparc.

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.

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.

Eric, any objections?

2011-09-16  David S. Miller  <davem@davemloft.net>

	* config/sparc/visintrin.h: New file.
	* config.gcc: Add it to extra_headers on sparc.

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

From: Jakub Jelinek <jakub@redhat.com>
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.

> 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.

From: Eric Botcazou <ebotcazou@adacore.com>
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.

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

From: Hans-Peter Nilsson <hp@bitrange.com>
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.
--------------------

On Wed, 21 Sep 2011, David Miller wrote:
> From: Hans-Peter Nilsson <hp@bitrange.com>
> 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

From: Hans-Peter Nilsson <hp@bitrange.com>
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.

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