Pointer semantics in GIMPLE

[Krister Walfridsson]

On Fri, 21 Mar 2025, Richard Biener wrote:

>>>> Issues
>>>> ------
>>>> The semantics I've described above result in many reports of
>>>> miscompilations that I haven't reported yet.
>>>>
>>>> As mentioned earlier, the vectorizer can use POINTER_PLUS_EXPR to generate
>>>> pointers that extend up to a vector length past the object (and similarly,
>>>> up to one vector length before the object in a backwards loop). This is
>>>> invalid if the object is too close to address 0 or 0xffffffffffffffff.
>>>>
>>>> And this out of bounds distance can be made arbitrarily large, as can be
>>>> seen by compiling the following function below for x86_64 with -O3:
>>>>
>>>> void foo(int *p, uint64_t s, int64_t n)
>>>> {
>>>>    for (int64_t i = 0; i < n; i++)
>>>>      {
>>>>        int *q = p + i * s;
>>>>        for (int j = 0; j < 4; j++)
>>>>         *q++ = j;
>>>>      }
>>>> }
>>>>
>>>> Here, the vectorized code add s * 4 to the pointer ivtmp_8 at the end of
>>>> each iteration:
>>>>
>>>>    <bb 5> :
>>>>    bnd.8_38 = (unsigned long) n_10(D);
>>>>    _21 = s_11(D) * 4;
>>>>
>>>>    <bb 3> :
>>>>    # ivtmp_8 = PHI <ivtmp_7(6), p_12(D)(5)>
>>>>    # ivtmp_26 = PHI <ivtmp_20(6), 0(5)>
>>>>    MEM <vector(4) int> [(int *)ivtmp_8] = { 0, 1, 2, 3 };
>>>>    ivtmp_7 = ivtmp_8 + _21;
>>>>    ivtmp_20 = ivtmp_26 + 1;
>>>>    if (ivtmp_20 < bnd.8_38)
>>>>      goto <bb 6>;
>>>>    else
>>>>      goto <bb 7>;
>>>>
>>>>    <bb 6> :
>>>>    goto <bb 3>;
>>>>
>>>> This means calling foo with a sufficiently large s can guarantee wrapping
>>>> or evaluating to 0, even though the original IR before optimization did
>>>> not wrap or evaluating to 0. For example, when calling foo as:
>>>>
>>>>    foo(p, -((uintptr_t)p / 4), 1);
>>>>
>>>> I guess this is essentially the same issue as PR113590, and could be fixed
>>>> by moving all induction variable updates to the latch.
>>>
>>> Yes.
>>>
>>> But if that
>>>> happens, the motivating examples for needing to handle invalid pointer
>>>> values would no longer occur. Would that mean smtgcc should adopt a more
>>>> restrictive semantics for pointer values?
>>>
>>> In principle yes, but PR113590 blocks this I guess.  Could smtgcc consider
>>> a SSA def to be happening only at the latest possible point, that is,
>>> "virtually"
>>> sink it to the latch?  (I realize when you have two dependent defs that can
>>> be moved together only such "virtual" sinking could be somewhat complicated)
>>
>> I think it feels a bit strange (and brittle) to define the semantics by
>> virtually sinking everything as much as possible. But isn't this sinking
>> just another way of saying that the operation is UB only if the value is
>> used? That is, we can solve this essentially the same way LLVM does with
>> its deferred UB.
>
> Yeah, that's another way of thinking.  Though technically GCC doesn't implement
> defered UB - for the case above we're simply lucky nothing exploits the UB
> that is in principle there.
>
>> The idea is that POINTER_DIFF_EXPR, PLUS_EXPR, etc. are defined for all
>> inputs, but the result is a poison value when it doesn't fit in the return
>> type. Any use of a poison value is UB.
>>
>> This is trivial to implement in smtgcc and would solve PR113590.
>
> I _think_ it's a reasonable thing for smtgcc to do.  For GCC itself it would
> complicate what is UB and what not quite a bit - what's the ultimate "use"
> UB triggers?  I suppose POISON + 1 is simply POISON again.  Can
> you store POISON to memory or is that then UB at the point of the store?
> Can you pass it to a call?  What if the call is inlined and just does
> return arg + 1?  IIRC I read some paper about this defered UB in LLVM
> and wasn't convinced they solve any real problem.

I agree deferred UB causes more problems than it solves... And I think 
it's important that smtgcc uses the same semantics as GCC, so I'll keep 
the current behavior.

    /Krister