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 autoconfisc
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 ov
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 w
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 t
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 whi
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/confi
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
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/t
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 tak
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 t
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 tr
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
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 co
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
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, whi
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
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 chang
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,
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 pac
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.
> 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
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
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
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, bu
24 matches
Mail list logo
