[llvm-dev] Legality of transformation

Mehdi AMINI via llvm-dev llvm-dev at lists.llvm.org
Sat Apr 4 10:23:13 PDT 2020


On Sat, Apr 4, 2020 at 9:33 AM Akash Banerjee via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Please consider the following C code:
>
>
>
>
>
>
>
>
>
>
> *    #define SZ 2048    int main(void) {      int A[SZ];      int B[SZ];
>     int i, tmp;      for (i = 0; i < SZ; i++) {        tmp = A[i];
> B[i] = tmp;      }      assert(A[SZ/2] == B[SZ/2]);    }*
>
> On running -O1 followed by -reg2mem I get the following IR:
>
>
>
>
>
>
>
>
>
>
>
>
>
> *define dso_local i32 @main() local_unnamed_addr #0 {entry:  %A = alloca
> [2048 x i32], align 16  %B = alloca [2048 x i32], align 16  %"reg2mem
> alloca point" = bitcast i32 0 to i32  %arrayidx3 = getelementptr inbounds
> [2048 x i32], [2048 x i32]* %A, i64 0, i64 1024  %0 = load i32, i32*
> %arrayidx3, align 16  %arrayidx4 = getelementptr inbounds [2048 x i32],
> [2048 x i32]* %B, i64 0, i64 1024  %1 = load i32, i32* %arrayidx4, align
> 16  %cmp5 = icmp eq i32 %0, %1  %conv = zext i1 %cmp5 to i32  %call = call
> i32 (i32, ...) bitcast (i32 (...)* @assert to i32 (i32, ...)*)(i32 %conv)
> #2  ret i32 0}*
>
> It is my understanding that in the original C code the assert would never
> fail, however in the optimized IR the assert might fail.
>

Reading uninitialized memory is undefined behavior in C I believe, so even
without talking about LLVM IR semantics your original program is incorrect
as soon a you read from A.

clang ub.c -fsanitize=memory && ./a.out

*==10365==WARNING: MemorySanitizer: use-of-uninitialized-value*

    #0 0x496ce7 in main (/tmp/a.out+0x496ce7)

    #1 0x7f2e71f27bba in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x26bba)

    #2 0x41e299 in _start (/tmp/a.out+0x41e299)


SUMMARY: MemorySanitizer: use-of-uninitialized-value (/tmp/a.out+0x496ce7)
in main

Exiting


-- 
Mehdi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200404/5495d0a2/attachment.html>


More information about the llvm-dev mailing list