Re: Patch: PR40900, extending call patterns

[Bernd Schmidt <bernds@codesourcery.com>]

On 05/05/2010 02:58 PM, Eric Botcazou wrote:
>> Seems to be because it's a signed operation, and arm has
>>
>> #define PROMOTE_MODE(MODE, UNSIGNEDP, TYPE)     \
>>   if (GET_MODE_CLASS (MODE) == MODE_INT         \
>>       && GET_MODE_SIZE (MODE) < 4)              \
>>     {                                           \
>>       if (MODE == QImode)                       \
>>         UNSIGNEDP = 1;                          \
>>       else if (MODE == HImode)                  \
>>         UNSIGNEDP = 1;                          \
>>       (MODE) = SImode;                          \
>>     }
>>
>> while ppc doesn't modify UNSIGNEDP.
> 
> Can't we be clever during RTL expansion and avoid blindly zero-extending the 
> value when we known that
> 
>   D.2014_1 = shortv2 ();
> 
> and promote_function_mode sign-extends?  The kind of extension for a specific 
> variable can be changed since the SUBREG_PROMOTED_* machinery records it.  In 
> other words, can't we just override promote_decl_mode in the SSA_NAME case of 
> expand_expr_real_1?

I've looked into this now, and I don't really see a way to do better at
rtl expansion time.

In current sources, the function ends up as
  D.2006_1 = shortv2 (); [tail call]
  return D.2006_1;

PROMOTE_MODE ensures that D.2006_1 becomes
  #0  store_expr (exp=0xf7cbb5e8, target=0xf7d2c5ac, call_param_p=0,
      nontemporal=0 '\000') at ../../trunk/gcc/expr.c:4582
  4582	      rtx inner_target = 0;
  (gdb) p target(gdb) p debug_rtx (target)
  (subreg/s/u:HI (reg:SI 133 [ D.2006 ]) 0)

We create zero-extensions around the CALL_EXPR in store_expr and call
expand_expr.  At some point, in expand_call, we create a signed target:
  (subreg/s:HI (reg:SI 136) 0)
which is returned from expand_call.  This value then gets zero extended
due to the NOP_EXPRs around the call which were previously created in
store_expr.  The zero extension makes it into initial RTL but is quickly
deleted as useless.

The value returned by the call to expand_expr in store_expr is simply
(reg:SI 133), with no hint that there was a sign-extended promoted
subreg available anywhere.

Later, during expand_return, we create the superfluous sign extension.
This seems unavoidable since
a) what we return is D.2006_1, i.e. a subreg of reg 133, so we no
   longer see the subreg created by expand_call, and
b) even if we did see it, it had its SUBREG_PROMOTED_VAR_P flag deleted
   anyway by this code in expand_expr_real_2:

	  /* If the signedness of the conversion differs and OP0 is
	     a promoted SUBREG, clear that indication since we now
	     have to do the proper extension.  */
	  if (TYPE_UNSIGNED (TREE_TYPE (treeop0)) != unsignedp
	      && GET_CODE (op0) == SUBREG)
	    SUBREG_PROMOTED_VAR_P (op0) = 0;

I see no obvious place in this sequence of events where we could have
done anything better, and I'm doubtful that arbitrarily ignoring the
choice made by PROMOTE_MODE at any point would be a good idea.  In light
of this, is my previous combiner patch OK?


Bernd