On Mon, Oct 13, 2025 at 2:03 PM Robin Dapp <[email protected]> wrote: > > >> In case I'm not missing the point now, my assumption was that once we reach > >> pointer size overflow doesn't matter any more (and original offset == new > >> offset == sizetype is OK). I guess that's equivalent to relying on two's > >> complement arithmetic which not all targets have? Or can we rely on that > >> nowadays? > > > > We can, GCC doesn't support anything else (for TYPE_UNSIGNED). > > Hmm, ok, just to make it more explicit for myself: > > If we have an > offset * 2 > where offset is an ssizetype (signed). Then, as usual, we assume that > undefined overflow does not happen. Consequently, a sizetype (unsigned), > wrapping operation is equivalent to the signed operation, even if the > new type is not larger. Do we need a diagnostic here to indicate we exploit > undefined overflow? > > For > offset * 2 > with offset being a sizetype (unsigned) we're wrapping and using a signed > offset type would only be correct if there is no wrap. Thus, we must check > if the new signed type is really 2x larger. That's what you were referring > to in the first place.
I think these are not exactly the relevant questions? For gather we have an offset mode and an indication whether that's interpreted as signed or unsigned by the target. I think it's documented that the scale is applied after widening the offset to pointer size. When we want to use an optab that does not match the operation we need to verify the resulting offsets are still valid. Since the scale is applied after widening and twos-complement happens, we can simply disregard that. To use a 'unsigned' optab with an original signed offset we have to make sure that the offset is either of pointer width, the offset is always positive, or we have to sign-extend offset to pointer width, thus use 'unsigned' + pointer-width gather. To use a 'signed' optab with an original unsigned offset we have to widen that to a offset type of double size and that has to be of max pointer size. When offset type is already of pointer-width we can argue - at least for scale > 1 - that even unsigned "overflow" there makes no sense (but technically we're lost). But it's always about interpreting all offset * scale values the same from the original GIMPLE and the target optab side. Richard. > -- > Regards > Robin >
