On Mon, Jun 20, 2022 at 11:48:24AM -0700, Noah Goldstein wrote:
> > I think we should differentiate more. If integer_nonzerop (chr)
> > or perhaps better tree_expr_nonzero_p (chr), then it is better
> > to optimize t = strlen (x); ... p = strchr (x, c); to
> > t = strlen (x); ... p = memchr (x, c, t);
> What do you mean by differentiate more? More comments? Or
> seperate the logic more?
Different code, don't add the 1 to the strlen value whenever you know
that chr can't be possibly 0 (either it is a non-zero constant,
or the compiler can prove it won't be zero at runtime otherwise).
Because if c is not 0, then memchr (x, c, strlen (x)) == memchr (x, c, strlen
(x) + 1),
either c is among the first strlen (x) chars, or it will return NULL
because x[strlen (x)] == 0.
It actually is slightly more complicated, strchr second argument is int,
but we just care about the low 8 bits.
For TREE_CODE (chr) == INTEGER_CST, it is still trivial,
say integer_nonzerop (fold_convert (char_type_node, chr))
or equivalent using wide-int.h APIs.
For SSA_NAMEs, we'd need get_zero_bits API, but we only have
get_nonzero_bits, but we could say at least handle the case where
get_ssa_name_range_info gives a VR_RANGE or set of them where none of
the ranges include integral multiplies of 256.
But for start perhaps just handling INTEGER_CST chr would be good enough.
Jakub
