This is the mail archive of the
mailing list for the GCC project.
Re: useless cast blocking some optimization in gcc 4.7.3
- From: Marc Glisse <marc dot glisse at inria dot fr>
- To: Laurent Alfonsi <laurent dot alfonsi at st dot com>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 8 Apr 2013 21:39:17 +0200 (CEST)
- Subject: Re: useless cast blocking some optimization in gcc 4.7.3
- References: <516316EF dot 6080806 at st dot com>
- Reply-to: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
On Mon, 8 Apr 2013, Laurent Alfonsi wrote:
I have identified a big performance regression between 4.6 and 4.7. (I have
enclosed a pathological test).
After investigation, it is because of the += statement applied on 2 signed
- It is now type-promoted to "int" when it is written "result += foo()".
- it is type promoted to "unsigned char" when it is written "result =
result + foo()".
The "char->int->char" cast is blocking some optimizations in later phases.
Anyway, this doesn't look wrong, so I extended fold optimization in order to
catch this case. (patch enclosed)
The patch basically transforms :
(TypeA) ( (TypeB) a1 + (TypeB) a2 ) /* with a1 and a2 of
the signed type TypeA */
a1 + a2
I believe this is legal for any licit a1/a2 input values (no overflow on
I don't think this is ok, please refer to the discussion around the
PR and patch that added this conversion, it was done on purpose.
According to this (4th item)
is perfectly defined and a is -56 (assuming a signed 8 bit char and a
strictly larger int). However, your transformation turns it into undefined
behavior: an addition that overflows in a type with