-
Notifications
You must be signed in to change notification settings - Fork 145
Description
compile the C code in the next post with clang15 and something roughly equivalent to "%clang -std=c11 -O0 -fno-unroll-loops -fno-tree-vectorize %s -S -emit-llvm -o - %newLoadClangEnzyme". The most important thing is -O0 so that things are clear. The code is really quite minimal in terms of both manifesting the bug in the llvm and at run time.
Some important variables to keep in mind when reading the llvm in my next post:
%10 is A's tape
%iv is A's loop counter
problem no. 1
The problem occurs when the original code exits via the B block. In this case the block return.loopexit is reached and the following is obviously a problem.
return.loopexit:
%19 = getelementptr inbounds i64, ptr %.lcssa27, i64 undef ; BAD
%20 = load i64, ptr %19, align 8, !invariant.group !6 ; %20 is supposed to be B's loop counter as loaded off of A's tapeproblem no. 2
"iv'ac.0" is used in invertA as A's reverse loop counter. This variable comes from the following places:
invertA:
%"iv'ac.0" = phi i64 [ %"iv'ac.1", %invertif.else ], [ %iv.lcssa, %invertA.loopexit9 ]
invertA.loopexit9:
%iv.lcssa = phi i64 [ %iv, %__enzyme_exponentialallocation.exit ] ; all good
invertif.else:
%"iv'ac.1" = phi i64 [ %40, %incinvertA ], [ %"iv'ac.2", %invertB.preheader ] ; all good. note %40 = %"iv'ac.0" - 1
invertB:
%"iv'ac.2" = phi i64 [ %"iv'ac.3", %invertif.else35 ], [ undef, %return.loopexit ] ; second is BAD
invertif.else35:
%"iv'ac.3" = phi i64 [ %40, %invertA.loopexit ], [ %"iv'ac.2", %incinvertB ] ; all goodAgain, it is clear that enzyme has gotten confused about invertA's loop counter when coming from invertB.