Bernd Schmidt writes:
> Wasn't Richard S. working on a patch to give constants modes?
A whole series more like. Don't hold your breath!
Richard
On 08/23/11 11:52, Jakub Jelinek wrote:
> On Tue, Aug 23, 2011 at 11:35:07AM +0200, Bernd Schmidt wrote:
>>> cse_process_notes_1
>>> perhaps could be changed for VOIDmode new_rtx to try to
>>> simplify_replace_rtx it...
>>
>> Is this where the problem came from? Sounds like it's worth a try.
>
> I
On Tue, Aug 23, 2011 at 11:35:07AM +0200, Bernd Schmidt wrote:
> > cse_process_notes_1
> > perhaps could be changed for VOIDmode new_rtx to try to
> > simplify_replace_rtx it...
>
> Is this where the problem came from? Sounds like it's worth a try.
In this case, yes. But there are many other pla
On Tue, Aug 23, 2011 at 11:35 AM, Bernd Schmidt wrote:
> On 08/23/11 11:05, Jakub Jelinek wrote:
>> On Mon, Jun 20, 2011 at 09:38:22PM +0200, Bernd Schmidt wrote:
>>> D'oh. Blackfin has a (clrsb:HI (operand:SI)) instruction, so adding this
>>> showed a problem with some of the existing simplify_co
On 08/23/11 11:05, Jakub Jelinek wrote:
> On Mon, Jun 20, 2011 at 09:38:22PM +0200, Bernd Schmidt wrote:
>> D'oh. Blackfin has a (clrsb:HI (operand:SI)) instruction, so adding this
>> showed a problem with some of the existing simplify_const_unop cases:
>> for ffs/clz/ctz/clrsb/parity/popcount, we
On Mon, Jun 20, 2011 at 09:38:22PM +0200, Bernd Schmidt wrote:
> D'oh. Blackfin has a (clrsb:HI (operand:SI)) instruction, so adding this
> showed a problem with some of the existing simplify_const_unop cases:
> for ffs/clz/ctz/clrsb/parity/popcount, we should look at the mode of the
> operand, rat
On Mon, 20 Jun 2011, Bernd Schmidt wrote:
> New patch below. Retested on i686 and bfin.
Yay, bikeshedding opportunity! :P
Can we call them "leading *repeated* sign bits"? (in docs and
comments) Calling them "redundant" makes you think the
representation is not two's complement but new and improv
On Mon, Jun 20, 2011 at 12:38 PM, Bernd Schmidt wrote:
> On 06/16/2011 06:25 PM, Richard Henderson wrote:
>> On 06/16/2011 05:44 AM, Bernd Schmidt wrote:
>>> +@deftypefn {Built-in Function} int __builtin_clrsb (unsigned int x)
>>> +Returns the number of leading redundant sign bits in @var{x}, star
On 06/20/2011 12:38 PM, Bernd Schmidt wrote:
> D'oh. Blackfin has a (clrsb:HI (operand:SI)) instruction, so adding this
> showed a problem with some of the existing simplify_const_unop cases:
> for ffs/clz/ctz/clrsb/parity/popcount, we should look at the mode of the
> operand, rather than the mode
On 06/16/2011 06:25 PM, Richard Henderson wrote:
> On 06/16/2011 05:44 AM, Bernd Schmidt wrote:
>> +@deftypefn {Built-in Function} int __builtin_clrsb (unsigned int x)
>> +Returns the number of leading redundant sign bits in @var{x}, starting
>> +at the most significant bit position.
>> +@end defty
On 06/16/2011 05:44 AM, Bernd Schmidt wrote:
> +@deftypefn {Built-in Function} int __builtin_clrsb (unsigned int x)
> +Returns the number of leading redundant sign bits in @var{x}, starting
> +at the most significant bit position.
> +@end deftypefn
Do we want a signed argument, since we're talking
On 06/16/2011 03:10 PM, Laurent Desnogues wrote:
> On Thu, Jun 16, 2011 at 2:44 PM, Bernd Schmidt
> wrote:
>> Several processors have a "count redundant sign bits" instruction:
>>
>> * SIGNBITS on Blackfin
>> * NORM on C6X
>> * SBC, apparently, on picochip
>
> picoChip defines __builtin_sbc. Wo
On Thu, Jun 16, 2011 at 2:44 PM, Bernd Schmidt wrote:
> Several processors have a "count redundant sign bits" instruction:
>
> * SIGNBITS on Blackfin
> * NORM on C6X
> * SBC, apparently, on picochip
picoChip defines __builtin_sbc. Wouldn't that make it redundant
with your __builtin_clrsb?
> and
Bernd Schmidt schrieb:
> Several processors have a "count redundant sign bits" instruction:
>
> * SIGNBITS on Blackfin
> * NORM on C6X
> * SBC, apparently, on picochip
>
> and probably others. For example, for a value of 0 or -1, it returns 31,
> while e.g. an input 0xc000 produces 1.
>
> Ot
14 matches
Mail list logo
