On Mon, 19 Jun 2023, Richard Sandiford wrote: > Jeff Law <jeffreya...@gmail.com> writes: > > On 6/16/23 06:34, Richard Biener via Gcc-patches wrote: > >> IVOPTs has strip_offset which suffers from the same issues regarding > >> integer overflow that split_constant_offset did but the latter was > >> fixed quite some time ago. The following implements strip_offset > >> in terms of split_constant_offset, removing the redundant and > >> incorrect implementation. > >> > >> The implementations are not exactly the same, strip_offset relies > >> on ptrdiff_tree_p to fend off too large offsets while split_constant_offset > >> simply assumes those do not happen and truncates them. By > >> the same means strip_offset also handles POLY_INT_CSTs but > >> split_constant_offset does not. Massaging the latter to > >> behave like strip_offset in those cases might be the way to go? > >> > >> Bootstrapped and tested on x86_64-unknown-linux-gnu. > >> > >> Comments? > >> > >> Thanks, > >> Richard. > >> > >> PR tree-optimization/110243 > >> * tree-ssa-loop-ivopts.cc (strip_offset_1): Remove. > >> (strip_offset): Make it a wrapper around split_constant_offset. > >> > >> * gcc.dg/torture/pr110243.c: New testcase. > > Your call -- IMHO you know this code far better than I. > > +1, but LGTM FWIW. I couldn't see anything obvious (and valid) > that split_offset_1 handles and split_constant_offset doesn't.
I think it's only the INTEGER_CST vs. ptrdiff_tree_p where the latter (used in split_offset_1) handles POLY_INT_CSTs. split_offset also computes the offset in poly_int64 and checks it fits (to some extent) while split_constant_offset simply converts all INTEGER_CSTs to ssizetype because it knows it starts from addresses only. An alternative fix would have been to rewrite signed arithmetic to unsigned in strip_offset_1. I wonder if we want to change split_constant_offset to record the offset in a poly_int64 and have a wrapper converting it back to a tree for data-ref analysis. Then we can at least put cst_and_fits_in_hwi checks in the code? The code also tracks a range so it doesn't look like handling POLY_INT_CSTs is easy there - do you remember whether that was important for IVOPTs? Thanks, Richard.
