This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Thread-safe profiling
Hi,
On Thu, 15 Mar 2007, Jan Hubicka wrote:
> Hmm, I guess I now see what your problem is - it is not the actuall call
> parameter promotion (since it only happen in calls.c that is not invoked
> yet), you simply get zero extended constant at input.
Right.
> I always believed that all const_int constants are supposed to be sign
> extended for their "mode" (that is defined sadly only from context they
> are used for and thus dificult to verify).
Hmm, that's an interesting notion. If we could agree to that, then it
might work, because ...
> This means that const_int 255 used as QImode is wrong and thus
> expand_expr is wrong to produce it when expanding QImode typed integer
> (that is your case).
... yes, this then would be incorrect. OTOH what would you propose that
expand_expr gives you, when presented with a tree
<integer_cst <unsigned char> 255>
and asked for a QImode target, with EXPAND_NORMAL? I guess (const_int -1)
would work.
> Formely we was conservative about the specific form (so for example
> x86_64_immediate_operand does the sign extension of mode it is given
> first), but some effort was put into avoding those "evil" constants
> (such as introduction of gen_int_mode and use of it in cases we can get
> into zero extension by "overflow") and now a lot of other code expect
> the sign extension - such as all the check comparing with constm1_rtx
> and const1_rtx.
>
> I am not sure what the current shape of mainline is - I tought the
> conversion was more or less completed, but if not, I would probably try
> to solve it on expand_expr side then.
Hmm, perhaps the cleanest thing. Probably all hell will break loose, but
hey ... :-)
Ciao,
Michael.