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: [TREE-SSA-CCP] Issue warning when folding condition


On 09/14/2016 03:00 AM, Richard Biener wrote:
On Tue, 13 Sep 2016, kugan wrote:

Hi Richard,


On 19/08/16 18:00, Richard Biener wrote:
On Fri, 19 Aug 2016, Kugan Vivekanandarajah wrote:

On 19 August 2016 at 12:09, Kugan Vivekanandarajah
<kugan.vivekanandarajah@linaro.org> wrote:
The testcase pr33738.C for warning fails with early-vrp patch. The
reason is, with early-vrp ccp2 is folding the comparison that used to
be folded in simplify_stmt_for_jump_threading. Since early-vrp does
not perform jump-threading is not optimized there.

Attached patch adds this warning to tree-ssa-ccp.c. We might also run
into some other similar issues in the future.

Sorry, I attached the wrong patch (with typo). Here is the correct one.

I think emitting this warning from GIMPLE optimizations is fundamentally
flawed and the warning should be removed there and put next to
the cases we alrady handle in c/c-common.c:shorten_compare (or in
FE specific code).  I see no reason why only VRP or CCP would
do the simplification for -fstrict-enums enums (thus it seems to be
missing from the generic comparison folders).

But, If I understand this correctly, I think we will not be able to fold all
the cases we handle in FE. Therefore we will not be able to warn there. For
very simple cases yes, but not for others.

Sure.  But I do not see an issue with that.  With GIMPLE level warnings
you have the general issue that the warning may be only exposed by
optimization (like cross-unit inlining with LTO) and thus would be
considered a false positive.
I must have missed a piece of this conversation.

If someone is going to add more stuff to shorten_compare, please break that function into two pieces. One which is non-destructive to the original trees and just emits warnings, the other which has the optimization.

There may well be code & work duplication, but that separation is one of the steps necessary to move the shortening bits out of the front-end and into match.pd.

jeff


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