[RFC][PATCH 2/3] Propagate and save value ranges wrapped information

Richard Biener rguenther@suse.de
Thu Apr 30 12:13:00 GMT 2015


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
(OVF) stuff.

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).

Richard.



More information about the Gcc-patches mailing list