--- Comment #21 from Richard Biener <rguenth at gcc dot> ---
The shift_bytes_in_array_{left,right} routines should go next to
native_{encode,interpret} where maybe also a comment should indicate how to
combine both?

The vn_reference_lookup_3 part looks OK to me, the visit_nary_op one is a bit
gross ... some comments:

+                 || wi::to_widest (TREE_OPERAND (b, 1)) != prec)

I think that one is guarateed by GIMPLE verification checking.

+                 tree nb = copy_node (b);
+                 TREE_TYPE (nb)
+                   = build_nonstandard_integer_type (last - first, 1);
+                 TREE_OPERAND (nb, 1) = bitsize_int (last - first);
+                 TREE_OPERAND (nb, 2)
+                   = size_binop (PLUS_EXPR, TREE_OPERAND (nb, 2),
+                                 bitsize_int (first));
+                 tree last_vuse = gimple_vuse (def);
+                 tree r = vn_reference_lookup (nb, gimple_vuse (def),
+                                               default_vn_walk_kind, NULL,
+                                               true, &last_vuse);

this asks for vn_reference_lookup_pieces to be used, first
copy_reference_ops_from_ref (outside of the loop) and then simply
modify the result in place (ops[0].op{0,1} should be the BIT_FIELD_REF
size/position.  That way you avoid the copy_node / ggc_free at least.

I guess in general it would be interesting to be able to prune lookups
by interesting bits for say

 short a[2];
 a[0] = 1;
 foo (a);
 a[1] = 2;
 bar (*(int *)a & 0xffff);

or more interesting cases with holes in the middle.  Decomposing the ref
and doing piecewise lookups is not so interesting.

I guess we could piggy back that on the partial-def support.  The
def walker tracks them in vn_walk_cb_data so if you make that available
to the caller of vn_reference_lookup[_pieces] then even upon failure
from the actual lookup the vn_walk_cb_data::partial_defs array still
contains reachable defs.  You could also "easily" seed the partial defs
state from the AND mask, simply claiming the uninteresting ranges are
alrady covered (that state is tracked in the known_ranges splay tree)
and the code would then upon completion of the interesting bits simply
not encode those parts and interpret from whatever is in the buffer
(we can zero it).

Which I guess means we could "fix" this by adding bit-precision/offset
support to partial defs tracking and support of that mask seeding.  Then
the visit_nary_op part would just do a single lookup.

Reply via email to