diff mbox

ptx preliminary rtl patches [3/4]

Message ID 541B2B36.6070102@codesourcery.com
State New
Headers show

Commit Message

Bernd Schmidt Sept. 18, 2014, 6:57 p.m. UTC 
On 09/12/2014 10:04 AM, Richard Biener wrote:
> On Thu, Sep 11, 2014 at 6:36 PM, Bernd Schmidt <bernds@codesourcery.com> wrote:
>> I strongly disagree. It's the same as for any other integer - there's one
>> sign bit, and since there aren't any other bits, the number of sign bit
>> copies is always exactly 1.
>
> I agree about that.  But I fail to see what goes wrong with the existing
> code in combine.  Maybe the code simply doesn't work for
> GET_MODE_PRECISION != GET_MODE_BITSIZE?

I had to debug it again - the patch was a year old. This time I came to 
the conclusion that we're just using the wrong mode. We're trying to 
simplify (ne:BI (reg:HI x) (const_int 0)), and the code here was using 
BImode when calling num_sign_bit_copies for the register - what I think 
it wants to do is verify that the operand consists of all zeros or all ones.

Digging a bit further I noticed that some of the cases around this code 
have a mode == GET_MODE (op0) test. These were added by rth in commit 
3573fd048, which added BImode. It looks like this particular case 
slipped through the cracks. The easiest way to fix it is the below - 
bootstrapped and tested on x86_64-linux, ok if it also works with ptx?


Bernd

Comments

Richard Biener Sept. 22, 2014, 8:55 a.m. UTC | #1 
On Thu, Sep 18, 2014 at 8:57 PM, Bernd Schmidt <bernds@codesourcery.com> wrote:
> On 09/12/2014 10:04 AM, Richard Biener wrote:
>>
>> On Thu, Sep 11, 2014 at 6:36 PM, Bernd Schmidt <bernds@codesourcery.com>
>> wrote:
>>>
>>> I strongly disagree. It's the same as for any other integer - there's one
>>> sign bit, and since there aren't any other bits, the number of sign bit
>>> copies is always exactly 1.
>>
>>
>> I agree about that.  But I fail to see what goes wrong with the existing
>> code in combine.  Maybe the code simply doesn't work for
>> GET_MODE_PRECISION != GET_MODE_BITSIZE?
>
>
> I had to debug it again - the patch was a year old. This time I came to the
> conclusion that we're just using the wrong mode. We're trying to simplify
> (ne:BI (reg:HI x) (const_int 0)), and the code here was using BImode when
> calling num_sign_bit_copies for the register - what I think it wants to do
> is verify that the operand consists of all zeros or all ones.
>
> Digging a bit further I noticed that some of the cases around this code have
> a mode == GET_MODE (op0) test. These were added by rth in commit 3573fd048,
> which added BImode. It looks like this particular case slipped through the
> cracks. The easiest way to fix it is the below - bootstrapped and tested on
> x86_64-linux, ok if it also works with ptx?

Ok.

Thanks,
Richard.

>
> Bernd
>
diff mbox

Patch

commit 3e1c88a4a16ccccc768e11fd56b881ed577fba33
Author: Bernd Schmidt <bernds@codesourcery.com>
Date:   Tue Sep 16 21:04:55 2014 +0200

    	* combine.c (combine_simplify_rtx): In STORE_FLAG_VALUE == -1 case,
    	also verify that mode is equal to the mode of op0.

diff --git a/gcc/combine.c b/gcc/combine.c
index 04863cb..efdd638 100644
--- a/gcc/combine.c
+++ b/gcc/combine.c
@@ -5801,10 +5801,11 @@  combine_simplify_rtx (rtx x, enum machine_mode op0_mode, int in_dest,
 	    ;
 
 	  else if (STORE_FLAG_VALUE == -1
-	      && new_code == NE && GET_MODE_CLASS (mode) == MODE_INT
-	      && op1 == const0_rtx
-	      && (num_sign_bit_copies (op0, mode)
-		  == GET_MODE_PRECISION (mode)))
+		   && new_code == NE && GET_MODE_CLASS (mode) == MODE_INT
+		   && op1 == const0_rtx
+		   && mode == GET_MODE (op0)
+		   && (num_sign_bit_copies (op0, mode)
+		       == GET_MODE_PRECISION (mode)))
 	    return gen_lowpart (mode,
 				expand_compound_operation (op0));