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: Thoughts on memcmp expansion (PR43052)


On 05/02/2016 02:52 PM, Richard Biener wrote:
+struct pieces_addr
+{
...
+  void *m_cfndata;
+public:
+  pieces_addr (rtx, bool, by_pieces_constfn, void *);

unless you strick private: somewhere the public: is redundant

Yeah, ideally I want to turn these into a classes rather than structs. Maybe that particular one can already be done, but I'm kind of wondering how far to take the C++ification of the other one.

Index: gcc/tree-ssa-forwprop.c
===================================================================
--- gcc/tree-ssa-forwprop.c     (revision 235474)
+++ gcc/tree-ssa-forwprop.c     (working copy)
@@ -1435,6 +1435,76 @@ simplify_builtin_call (gimple_stmt_itera
             }
         }
        break;
+
+    case BUILT_IN_MEMCMP:
+      {

I think this doesn't belong in forwprop.  If we want to stick it into
a pass rather than
folding it should be in tree-ssa-strlen.c.

This part (and the other one you quoted) was essentially your prototype patch from PR52171. I can put it whereever you like, really.

Note that we can handle size-1 memcmp even for ordered compares.

One would hope this doesn't occur very often...

Jakub, where do you think this fits best?  Note that gimple-fold.c may
not use immediate uses but would have to match this from the
comparison (I still have to find a way to handle this in match.pd where
the result expression contains virtual operands in the not toplevel stmt).


Bernd


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