This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Fix overzealous folding


On Tue, May 27, 2008 at 8:55 PM, Mark Mitchell <mark@codesourcery.com> wrote:
> Eric Botcazou wrote:
>>>
>>> In C/C++, ENUMERAL_TYPEs and INTEGER_TYPEs are very closely related.
>>> I'd be pretty surprised if I writing my code with int-sized enums
>>> instead of ints caused different behavior.  So, I don't think the patch
>>> as written makes sense.
>>
>> The argument is a little specious since we're talking about optimization
>> here and this is not allowed to change the (visible) behavior of a valid
>> program.
>> So either your code with int-sized enums behaved the same as your code
>> with ints before the patch and it still should, or it didn't and it still
>> should.
>
> Right, but they shouldn't be optimized differently!  Performance shouldn't
> depend on whether I use an "int" or an int-sized enum.

C++ sets TYPE_MIN/MAX_VALUE on enum types and VRP in some circumstances
picks up these min/max values as bounds of derved value ranges.  We even have
a testcase for that.  IMHO this behavior of VRP should go, as to the middle-end
a type with same precision but different TYPE_MIN/MAX_VALUE is no different.
But of course a testcase for this optimization hints at the fact that somebody
implemented this on purpose.

Still I'd like to remove more and more uses of TYPE_MIN/MAX_VALUE from the
middle-end, as as sonn as they deviate from what TYPE_PRECISION would allow
for TYPE_MIN/MAX_VLAUE the treatment and honoring in the middle-end is
not at all consistent.

Richard.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]