On 06/08/14 22:09, Richard Biener wrote: > On Tue, Aug 5, 2014 at 4:21 PM, Jakub Jelinek <ja...@redhat.com> wrote: >> On Tue, Aug 05, 2014 at 04:17:41PM +0200, Richard Biener wrote: >>> what's the semantic of setting SRP_SIGNED_AND_UNSIGNED >>> on the subreg? That is, for the created (subreg:lhs_mode >>> (reg:<PROMOTE_MODE of ssa> N))? >> >> SRP_SIGNED_AND_UNSIGNED on a subreg should mean that >> the subreg is both zero and sign extended, which means >> that the topmost bit of the narrower mode is known to be zero, >> and all bits above it in the wider mode are known to be zero too. >> SRP_SIGNED means that the topmost bit of the narrower mode is >> either 0 or 1 and depending on that the above wider mode bits >> are either all 0 or all 1. >> SRP_UNSIGNED means that regardless of the topmost bit value, >> all above wider mode bits are 0. > > Ok, then from the context of the patch we already know that > either SRP_UNSIGNED or SRP_SIGNED is true which means > that the value is sign- or zero-extended. > > I suppose inside promoted_for_type_p > TYPE_MODE (TREE_TYPE (ssa)) == lhs_mode, I'm not sure > why you pass !unsignedp as lhs_uns.
In expand_expr_real_1, it is already known that it is promoted for unsigned_p and we are setting SUBREG_PROMOTED_SET (temp, unsignedp). If we can prove that it is also promoted for !unsignedp, we can set SUBREG_PROMOTED_SET (temp, SRP_SIGNED_AND_UNSIGNED). promoted_for_type_p should prove this based on the value range info. > > Now, from 'ssa' alone we can't tell anything about a larger mode > registers value if that is either zero- or sign-extended. But we > know that those bits are properly zero-extended if unsignedp > and properly sign-extended if !unsignedp? > > So what the predicate tries to prove is that sign- and zero-extending > results in the same larger-mode value. This is true if the > MSB of the smaller mode is not set. > > Let's assume that smaller mode is that of 'ssa' then the test > is just > > return (!tree_int_cst_sign_bit (min) && !tree_int_cst_sign_bit (max)); > > no? hmm, is this because we will never have a call to promoted_for_type_p with same sign (ignoring PROMOTE_MODE) for 'ssa' and the larger mode. The case with larger mode signed and 'ssa' unsigned will not work. Therefore larger mode unsigned and 'ssa' signed will be the only case that we should consider. However, with PROMOTE_MODE, isnt that we will miss some cases with this. Thanks, Kugan
