This is the mail archive of the
mailing list for the GCC project.
Re: [RFC][PATCH 2/3] Propagate and save value ranges wrapped information
- From: Richard Biener <rguenther at suse dot de>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Richard Biener <richard dot guenther at gmail dot com>, Kugan <kugan dot vivekanandarajah at linaro dot org>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, Jeff Law <law at redhat dot com>
- Date: Thu, 30 Apr 2015 14:12:14 +0200 (CEST)
- Subject: Re: [RFC][PATCH 2/3] Propagate and save value ranges wrapped information
- Authentication-results: sourceware.org; auth=none
- References: <54B9C2EE dot 4050100 at linaro dot org> <54B9C45B dot 3010704 at linaro dot org> <alpine dot LSU dot 2 dot 11 dot 1501191223460 dot 12482 at zhemvz dot fhfr dot qr> <55381C83 dot 4040304 at linaro dot org> <CAFiYyc0QFy0bbtmvsLcLV3fXisOg-mKBTNxW_SkMho0R8Jmi-g at mail dot gmail dot com> <20150430114010 dot GO1751 at tucnak dot redhat dot com>
On Thu, 30 Apr 2015, Jakub Jelinek wrote:
> On Thu, Apr 30, 2015 at 01:35:25PM +0200, Richard Biener wrote:
> > I've long pondered with replacing the VRP overflow checking code
> > (for -fstrict-overflow) with keeping two lattices - one honoring undefined
> > overflow and one not and then comparing the results in the end.
> Yeah, that would be greatly appreciated. The (OVF) stuff is complete mess.
Just to explain a little bit, the idea is to have two lattices
and run the VRP propagation stage on each one, once with
flag_wrapv forced to 1 (all conditional on -Wstrict-overflow of course).
At stmt simplifiation time then determine if the outcome is dependent
on the choice of the lattice and if so, emit a strict-overflow warning.
This will avoid the missed optimizations we currently have due to the
And it will simplify the code and make it easier to maintain.
As for doing sth similar for PROMOTE_MODE you'd have to replace
all SSA names TREE_TYPE (and hope VRP doesn't explode on inconsistencies).
I don't think thats going to fly well though. Instead you could
"lower" at VRP instrumentation time, inserting sign-/zero-extensions
and remove those not necessary at VRPs final stage. Of course that
would tie lowering to VRP which probably we don't want to do.
I've meanwhile found the prototype lowering pass and as I've commented
on that patch you need to add at least a sign-extension tree operator
for efficiency (otherwise you need two stmts and an intermediate
non-promoted type). zero-extension can be done via a BIT_AND_EXPR
(not 100% nice, but we avoid having two ways to compute sth which
speaks against having an explicit zero-extension operator).