ptx preliminary rtl patches [3/4]

Richard Biener richard.guenther@gmail.com
Fri Sep 12 08:04:00 GMT 2014


On Thu, Sep 11, 2014 at 6:36 PM, Bernd Schmidt <bernds@codesourcery.com> wrote:
> On 09/11/2014 06:34 PM, Steven Bosscher wrote:
>>
>> On Thu, Sep 11, 2014 at 6:19 PM, Bernd Schmidt wrote:
>>>>>
>>>>> What do you expect that function to do different? It returns the
>>>>> correct
>>>>> value.
>>>>>
>>>>
>>>> No different. Just that if you want to check whether DECL is a global
>>>> variable then we have a predicate for it. So why use TREE_STATIC
>>>> instead?
>>>>
>>>> In other words: Just trying to make/keep certain checks consistent. (A
>>>> hopeless cause, but a noble one... ;-)
>>>
>>>
>>>
>>> You're talking about a different patch here. This one is about
>>> num_sign_bit_copies.
>>
>>
>>
>> Ah. *sigh* can't even keep two patches in my mind at any one time.
>>
>> The point about num_sign_bit_copies is that it doesn't really return
>> the correct value IMHO, if there isn't really a correct value to speak
>> of: What is the sign of TRUE or FALSE, the only two values a BImode
>> value can take?
>>
>> A 1-bit precision integer can have value 0 or -1 and in that case
>> num_sign_bit_copies should be 0. But for a BImode value, it seems to
>> me that asking for the sign bit or sign bit copies is just wrong.
>
>
> 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?

At least your new comment doesn't explain anything to me.

Richard.


>
> Bernd
>
>



More information about the Gcc-patches mailing list