On Fri, 28 Apr 2017, Richard Biener wrote:
On Fri, Apr 28, 2017 at 1:35 PM, Marc Glisse <marc.gli...@inria.fr> wrote:
Hello,
surprisingly, this did not cause any Wstrict-overflow failure. Some of it
sounds more like reassoc's job, but it is convenient to handle simple cases
in match.pd. I think we could wait until there are reports of regressions
related to register pressure before adding single_use tests.
For a std::vector<long> v, we now simplify v.size()==v.capacity() to a
single comparison (long)finish==(long)end_storage (I guess I could still try
to drop the casts to consider it really done). Handling
v.size()<v.capacity() seems much harder, because of C++'s questionable
choice to use unsigned types. I may still be able to remove the divisions,
I'll see if I can sprinkle some 'convert' in recent transformations.
Bootstrap+regtest on powerpc64le-unknown-linux-gnu.
+(for cmp (eq ne minus)
Fat fingered 'minus' (in all places) or did you want to get fancy?
(the transforms
look valid even for cmp == minus) Maybe adjust comments to reflect this.
I started with just comparisons and then noticed that minus worked as
well. I'll adjust the comment and rename cmp to op as suggested by Jakub.
I may have to separate the minus case when I add converts in a future
patch.
There are a few related cases in fold-const.c, namely X +- Y CMP X -> Y CMP 0,
some of them also handling POINTER_PLUS_EXPR. So I wonder if you can
handle pointer_plus like plus and maybe move those fold-const.c patterns.
You already added (T)(P + A) - (T)(P + B) -> (T)A - (T)B, so I'll have to
take care to avoid redundancy. Since it was meant for pointer_plus more
than plus, you used convert, not convert?, and it is currently not
redundant with my patch. If I integrate pointer_plus in the same
transformation, I will probably have to use :C instead of :c, and we will
get 2 dead paths (operand_equal_p on the first argument of one
pointer_plus and the second argument of another pointer_plus), it might be
easier as a separate pattern.
--
Marc Glisse
