On Fri, Jan 15, 2016 at 2:32 PM, Jeff Law <l...@redhat.com> wrote: > On 01/14/2016 11:14 AM, Jeff Law wrote: >> >> On 01/14/2016 12:49 AM, Jakub Jelinek wrote: >>> >>> On Thu, Jan 14, 2016 at 08:46:43AM +0100, Jakub Jelinek wrote: >>>> >>>> On Thu, Jan 14, 2016 at 12:38:52AM -0700, Jeff Law wrote: >>>>> >>>>> + /* An integral type with more precision, but the object >>>>> + only takes on values [0..1] as determined by VRP >>>>> + analysis. */ >>>>> + wide_int min, max; >>>>> + if (INTEGRAL_TYPE_P (TREE_TYPE (op)) >>>>> + && get_range_info (op, &min, &max) == VR_RANGE >>>>> + && wi::eq_p (min, 0) >>>>> + && wi::eq_p (max, 1)) >>>>> + return true; >>>> >>>> >>>> You could use and/or: >>>> if (INTEGRAL_TYPE_P (TREE_TYPE (op)) && wi::eq_p (get_nonzero_bits >>>> (op), 1)) >>>> set_range_info for VR_RANGE should usually update also the non-zero >>>> bits, but >>>> set_nonzero_bits does not update the recorded range. >>> >>> >>> Though, that would need to be limited to TYPE_PRECISION (TREE_TYPE >>> (op)) > 1 >>> or TYPE_UNSIGNED. >> >> Quite surprisingly, this does seem to do better fairly often. Usually >> it's just getting more constants into the PHI nodes without further >> improvements. However occasionally I see a PHI that turns into a >> constant, which is then propagated to a use where we're able to simplify >> some arithmetic/logical. >> >> Unfortunately it doesn't make a bit of difference in the final output, >> so something post DOM was picking up these anyway (most likely VRP2). >> But I'm a fan of getting stuff optimized earlier in the pipeline when >> it's reasonable to do so, and this seems reasonable. >> >> Limiting to TYPE_PRECISION > 1 or TYPE_UNSIGNED ought to be trivial. > > So further testing did show some code regressions from this improvement. > Specifically we were clearly better at propagating boolean values derived > from test conditions into PHIs (and ultimately into real statements as > well). That was the purpose of the patch. > > Where we took a small step backwards was the out-of-ssa translation and RTL > expansion. A constant argument in a PHI generates a constant load at RTL > time. We have uncprop to detect cases where there are already objects > holding the value we want and just before out-of-ssa we un-propagate the > constant. When the object holding the value we want coalesces with the LHS > of the PHI (which is most of the time) we win. > > uncprop wasn't catching these new cases where we'd propagated constants more > aggressively into PHI nodes. This patch fixes that problem. > > In all, this is a very small improvement in the generated code. It may > ultimately prove more useful in the future to drive path partitioning. > > There's two small tests. One verifies we're able to propagate more > constants per the original intent of the patch. The other verifies we > un-propagate as well. > > > Bootstrapped and regression tested on x86_64. Installed on the trunk. > > jeff > > > > commit 1384b36abcd52a7ac72ca6538afa2aed2e04f8e0 > Author: Jeff Law <l...@tor.usersys.redhat.com> > Date: Fri Jan 15 17:15:24 2016 -0500 > > PR tree-optimization/69270 > * tree-ssanames.c (ssa_name_has_boolean_range): Moved here from > tree-ssa-dom.c. Improve test for [0..1] ranve from VRP. > * tree-ssa-dom.c (ssa_name_has_boolean_range): Remove. > * tree-ssanames.h (ssa_name_has_boolean_range): Prototype. > * tree-ssa-uncprop.c (associate_equivalences_with_edges): Use > ssa_name_has_boolean_range and constant_boolean_node. > > PR tree-optimization/69270 > * gcc.dg/tree-ssa/pr69270-2.c: New test. > * gcc.dg/tree-ssa/pr69270-3.c: New test. >
This caused: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70005 H.J.
