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: Drop Z from X + Z < Y + Z


On Fri, 28 Apr 2017, Richard Biener wrote:

On Fri, Apr 28, 2017 at 1:35 PM, Marc Glisse <marc.glisse@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


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