On Thu, Sep 11, 2014 at 6:36 PM, Bernd Schmidt <ber...@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 > >
