Thread-safe profiling

Michael Matz matz@suse.de
Thu Mar 15 19:51:00 GMT 2007


Hi,

On Thu, 15 Mar 2007, Ian Lance Taylor wrote:

> > The tree argument 1 will be: <integer_cst <unsigned char> 255>, which 
> > is correct, as the prototype for this builtin indeed has an unsigned 
> > char integer type in arguments.  Now the expand_expr above will turn 
> > that into (const_int 255 [0xff]), also still sort of correct.
> 
> That doesn't sound right.  immed_double_const with QImode should return 
> const_int 0xffffffff here.  Why do we have 0xff?

Hmm, I know why.  I didn't tell the truth.  The input tree actually is:

<integer_cst type <integer_type int> constant invariant 255>

That is due to default promotion (after all this is an argument to a 
builtin "call"), so this 255 actually has 'int' type.  Hence we're going 
to these relevant code line in expand_expr_real_1:

...
      type = TREE_TYPE (exp);
      mode = TYPE_MODE (type);
      unsignedp = TYPE_UNSIGNED (type);
...
[ mode is now SImode, unsignedp is 0, and tmode (argument to expand_expr) 
is QImode ]
...
    case INTEGER_CST:
      temp = immed_double_const (TREE_INT_CST_LOW (exp),
                                 TREE_INT_CST_HIGH (exp), mode);
      if (TREE_OVERFLOW (exp)
          && modifier != EXPAND_INITIALIZER)
        temp = force_reg (mode, temp);

      return temp;

Here immed_double_const is called with SImode (the mode of the inherent 
type of the input tree, not the target mode, which isn't used in this case 
at all), so the value of (const_int 255) is explainable.  Sorry for 
confusing matters even more :-(

The above is okay, as TMODE is only a suggestion for expand_expr.  That's 
why there is a need for convert_to_mode for most cases, except that it 
doesn't work fully with 2*HOST_BITS_PER_WIDE_INT constants.

Which also makes Honzas suggestion of fixing expand_expr to return 
(const_int -1) mood.  OTOH this then makes Honzas other suggestion not 
being a no-op anymore, namely using TYPE_MODE (TREE_TYPE (CALL_EXPR_ARG 
(exp, 1))) as old_mode for a convert_modes call, at least when the 
returned value from expand_expr has no mode itself.  Hmm, seems like a 
hack, though, but seems to work in my quick test.


Ciao,
Michael.



More information about the Gcc-patches mailing list