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 Thu, May 29, 2008 at 2:48 PM, Eric Botcazou <ebotcazou@adacore.com> wrote:
>> Even if so, there's no reason to make the problem worse!
>
> I think it depends by how much, say in percentage.  First of all, the
> "equivalence" principle was already violated, just compile at -O2
>
> eric@linux:~/build/gcc/native32> cat t.cc
> extern void abort (void);
>
> #ifdef TRUE_ENUM
>
> typedef enum { FIRST = 1, SECOND = 2, THIRD = 3 } my_enum;
>
> #else
>
> typedef int my_enum;
>
> #define FIRST  1
> #define SECOND 2
> #define THIRD  3
>
> #endif
>
> int valid(my_enum v)
> {
>  if (FIRST <= v && v <= THIRD)
>    return 1;
>  else
>    abort();
> }
>
> with or without defining TRUE_ENUM.  I think that we can agree that it's not a
> small violation, so let's say the principle is already violated in 50% of the
> cases for typical C++ code using enumeration types.
>
> As I previously said, I'd think that the case at hand (casting back to an
> enumeration type the result of a bitwise manipulation) is pretty rare, so
> let's the additional violation is 1%.
>
> So the trade off is: 51% vs 50% of violation, or non-negligible work in the
> middle-end or VRP that may have far reaching consequences.  In my opinion
> it's worth at least considering.

Note that I tried to dig around to find the real problem, and Eric has done
the same.  But in the end my prefered choice would have been to remove
the optimization for ENUM_TYPEs from VRP and the current fix is the
way more pragmatic one.

Richard.


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