Thoughts on memcmp expansion (PR43052)
Bernd Schmidt
bschmidt@redhat.com
Mon May 2 12:57:00 GMT 2016
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
More information about the Gcc-patches
mailing list