This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Revisiting the TYPE_IS_SIZETYPE issue
On Mon, May 26, 2008 at 8:19 PM, Paolo Bonzini <bonzini@gnu.org> wrote:
> Richard Guenther wrote:
>>
>> On Mon, May 26, 2008 at 12:23 PM, Paolo Bonzini <bonzini@gnu.org> wrote:
>>>>
>>>> So my idea (I have this for some time now, but there's always lack
>>>> of time to implement it ...) is to make the existing tree codes
>>>> 'may overflow' operations and introduce new tree code variants
>>>> with the 'does not overflow' semantics. This way we conservatively
>>>> preserve 'may overflow' in legacy code.
>>>
>>> That seems extremely ugly, especially to make fold-const.c aware of that.
>>> It would be better to make the "overflow definition" a flag for a single
>>> PLUS_EXPR node (or PLUS rtl).
>>
>> That obviously doesn't work. As fold operates on "destructed" trees
>> you have no way of placing the flag somewhere.
>
> I'm definitely rusty. I guess modifying fold to add an argument does not
> make sense, but changing all x == PLUS_EXPR to PLUS_EXPR_P (x) is also a
> nightmare.
Well, sure. But one way we need to go - it will definitely be a
"nightmare" (just
like tuples is a "nightmare"). The question is what is the cleaner
way and I have
come to the conclusion myself that extra tree codes are it. We'll have similar
situation with the various floating-point semantic changing flags btw.
An alternative solution I considered for a short time is to simply
wrap operations
with different semantics into yet-another no-op operation (like we now have
PAREN_EXPR to avoid re-association for floating-point operations). But that's
definitely in the same ugliness class than more tree codes, extra flag arguments
for all decomposed tree functions and flags on tree codes :/
Richard.