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] |
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] |