| Message ID | CAFiYyc3Nvb3Om81Fs6eGpc7oOkvQxJD7Qa_RP-AQh3x_-w-LRw@mail.gmail.com |
|---|---|
| State | New |
| Headers | show |
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
On Mon, May 2, 2016 at 2:57 PM, Bernd Schmidt <bschmidt@redhat.com> wrote: > 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. I think it fits best in tree-ssa-strlen.c:strlen_optimize_stmt for the moment. >> Note that we can handle size-1 memcmp even for ordered compares. > > > One would hope this doesn't occur very often... C++ templates .... but yes. Richard. > >> 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: 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. + if (tree_fits_uhwi_p (len) + && (leni = tree_to_uhwi (len)) <= GET_MODE_SIZE (word_mode) + && exact_log2 (leni) != -1 + && (align1 = get_pointer_alignment (arg1)) >= leni * BITS_PER_UNIT + && (align2 = get_pointer_alignment (arg2)) >= leni * BITS_PER_UNIT) + { + location_t loc = gimple_location (stmt2); + tree type, off; + type = build_nonstandard_integer_type (leni * BITS_PER_UNIT, 1); + gcc_assert (GET_MODE_SIZE (TYPE_MODE (type)) == leni); + off = build_int_cst + (build_pointer_type_for_mode (char_type_node, ptr_mode, true), 0); + arg1 = build2_loc (loc, MEM_REF, type, arg1, off); + arg2 = build2_loc (loc, MEM_REF, type, arg2, off); + res = fold_convert_loc (loc, TREE_TYPE (res), + fold_build2_loc (loc, NE_EXPR, + boolean_type_node, + arg1, arg2)); + gimplify_and_update_call_from_tree (gsi_p, res); + return true; + } for this part see gimple_fold_builtin_memory_op handling of /* If we can perform the copy efficiently with first doing all loads and then all stores inline it that way. Currently efficiently means that we can load all the memory into a single integer register which is what MOVE_MAX gives us. */ we might want to share a helper yielding the type of the load/store or NULL if not possible. Note that we can handle size-1 memcmp even for ordered compares. 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). Richard. > > Bernd