From: Richard Henderson
Date: Mon, 03 Oct 2011 09:49:37 -0700
> You might have a look at the "Vector Shuffle" thread, where we've been
> trying to provide builtin-level access to this feature. We've not added
> an rtx-level code for this because so far there isn't *that* much in
> common between
On 10/02/2011 10:28 PM, David Miller wrote:
>> (set (reg:DI GSR_REG)
>> (unspec:DI [(match_dup 1) (match_dup 2) (reg:DI GSR_REG)]
>> UNSPEC_BMASK))
>
> Actually, can't we just use a (zero_extend:DI (plus:SI ...)) for the
> 32-bit case? It seems to work fine.
Sure.
>>>
From: Richard Henderson
Date: Fri, 30 Sep 2011 14:03:52 -0700
> On 09/30/2011 12:59 AM, David Miller wrote:
>>
>>[ VIS 2.0 bmask patterns ]
>
> I think this is wrong. I think you want to model this as
>
> [(set (match_operand:DI 0 "register_operand" "=r")
> (plus:DI (match_operand:DI
From: Richard Henderson
Date: Fri, 30 Sep 2011 14:03:52 -0700
> (3) Use optimize-mode-switching to minimize the number of changes
> to the global state. This includes the use of SIAM vs %fsr,
> especially when a subroutine call could have changed the
> global rounding mode.
On Fri, 30 Sep 2011, Richard Henderson wrote:
> Specifically, in-compiler support for #pragma STDC FENV_ACCESS and the
> various routines. We ought to be able to track the rounding
> mode (and other relevant parameters) on a per-expression basis, tagging
> each floating-point operation with the
On 09/30/2011 12:59 AM, David Miller wrote:
>
> I tried to add the 'siam' instruction too but that one is really
> difficult because it influences the behavior of every float operation
> and I couldnt' find an easy way to express those dependencies. I
> tried a few easy approaches but I couldn't
I tried to add the 'siam' instruction too but that one is really
difficult because it influences the behavior of every float operation
and I couldnt' find an easy way to express those dependencies. I
tried a few easy approaches but I couldn't reliably keep the compiler
from moving 'siam' across f
