InstSimplify unconditionally executed trapping constant expression in phi fold

[zhendongsu]

Bugzilla Link	50495
Version	trunk
OS	All
CC	@rotateright

Extended Description

[585] % clangtk -v
clang version 13.0.0 (https://github.com/llvm/llvm-project.git 5dd86aa)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /local/suz-local/opfuzz/bin
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.5.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.5.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/8
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.5.0
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Candidate multilib: x32;@MX32
Selected multilib: .;@m64
[586] %
[586] % clangtk -O2 small.c; ./.aout
bash: ./.aout: No such file or directory
[587] %
[587] %
[587] % clangtk -v
clang version 13.0.0 (https://github.com/llvm/llvm-project.git 5dd86aa)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /local/suz-local/opfuzz/bin
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.5.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.5.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/8
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.5.0
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Candidate multilib: x32;@MX32
Selected multilib: .;@m64
clang-13: warning: argument unused during compilation: '-I /usr/local/include/csmith' [-Wunused-command-line-argument]
[588] %
[588] % clangtk -O2 small.c; ./a.out
[589] %
[589] % clangtk -O3 small.c
[590] % ./a.out
Floating point exception
[591] %
[591] % cat small.c

int a, b, e[2], f;
static char c, d, *g = &c, **h = &g;
char i(char j, char k) { return k ? j % k : 0; }
int main() {
  int *l = &e[1];
  for (; d < 1; d++) {
    int *m = &a, *o = &e[1];
    **h = l == m;
    char ***n[2] = {&h, &h};
    for (; b < 4; ++b)
      if (f != 1)
        *o = i(1, *g);
  }
  return 0;
}

[rotateright]

This is still visible. I see srem and constant expressions in the IR, so some pass is likely hoisting an op without checking that it is safe to speculate.

[fhahn]

Still reproduces: https://godbolt.org/z/fx5j9zh49

According to GodBolt this started happening between 11.0 and 12.0: https://godbolt.org/z/hPrEb6a5E

[fhahn]

The culprit seems to be instsimplify: https://godbolt.org/z/9xW8d3a1e

For the input, it sinks the srem to the a constant expression in the phi node in the successor block, which will then be unconditionally executed after lowering in the backend. The transformation is invalid according to Alive2

@e = external global [2 x i32]
@a = external global i32

define <2 x i8> @main(i1 %c) {
entry:
  br i1 %c, label %then, label %exit

then:
  %srem = srem i8 1, zext (i1 icmp eq (i32* getelementptr inbounds ([2 x i32], [2 x i32]* @e, i64 0, i64 1), i32* @a) to i8)
  %ins = insertelement <2 x i8> zeroinitializer, i8 %srem, i64 0
  br label %exit

exit:
  %p = phi <2 x i8> [ zeroinitializer, %entry ], [ %ins, %then ]
  ret <2 x i8> %p
}

[fhahn]

I think instsimplify shouldn't move the code, but I'm tagging a couple of people for additional opinions about movement of constant expressions that may trap. @nikic @nunoplopes @preames @rotateright @LebedevRI

[rotateright]

Thanks for tracking this down!
Yes, it seems likely that we should just bail out of the transform.
I didn't step through this example yet - can we use isSafeToSpeculativelyExecute on the path where the transform is attempted? That's what we use to guard against moving div/rem ops in other passes.

[nikic]

Hm, I'm not so sure here. Intuitively I would say this transform is correct, because phi values are materialized on the incoming edge, not in the phi block. LangRef says:

For the purposes of the SSA form, the use of each incoming value is deemed to occur on the edge from the corresponding predecessor block to the current block (but after any definition of an ‘invoke’ instruction’s return value on the same edge).

I would say it's a backend bug if the backend materializes a trapping constant expression in the phi block. It should happen on the edge (possibly a split critical edge).

But then alive2 says the transform is not valid, so possibly my understanding of the semantics is not correct.

[nikic]

Thinking about this a bit more, I think this transform must be valid, otherwise doing RAUW with a constant folding result would be illegal, which would be very bad. I think the alive2 modelling isn't correct in this instance, because it places the constexpr evaluation in the wrong block.

[fhahn]

But then alive2 says the transform is not valid, so possibly my understanding of the semantics is not correct.

Yes that was my original thought as well, the incoming value should only execute when the edge is executed.

[LebedevRI]

I agree that as per langref the backend is at fault here.
Filed AliveToolkit/alive2#781

[nunoplopes]

What if a phi BB's predecessor has multiple successors?
There's no execution on an edge, only on BBs. Do we assume the execution happens in the predecessor on in an imaginary BB in-between?
e.g.:

br %cond, then, else

then:
phi [ div... ]

is this the same as:

%x = div ...
br %cond, then, else

then:
phi [ %x ]

or:

br %cond, then_0, else

then_0:
%x = div ...
br then

then:
phi [ %x ]