[llvm-dev] Is this a bug or is llvm processing conservative?

Hiroshi Yamauchi via llvm-dev llvm-dev at lists.llvm.org
Tue Apr 28 09:56:44 PDT 2020


Perhaps "(*b)[2]" is out of bounds?

On Mon, Apr 27, 2020 at 8:57 PM Panyuntao(Compiler) via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Hi, All developers:
>
>
>
> *I have this code. For (*b)[2], It is reasonable that llvm thinks it's
> unaligned access. and I think the array pointer always points to 4 - byte
> aligned array elements.*
>
>
>
> CMD: clang  --target=arm-none-eabi -mcpu=cortex-r52 -mthumb -O0 -emit-llvm
> -S test.c -o test.ll
>
> *LLVM think it’s an align 1 store, I don't think so.*
>
> CMD: llc -mattr=+strict-align test.ll
>
> *If the CPU does not support non-aligned access, The access is divided
> into four one-byte access.*
>
>
>
> CMD: llc -mattr=-strict-align test.ll
>
> *If the CPU support non-aligned access, It's a normal four-byte access.*
>
>
>
> *But gcc always think it’s an aligned access ,and processed him as a
> four-byte access. I think this is reasonable.*
>
> CMD1: arm-none-eabi-gcc -mcpu=cortex-r52 -mthumb  -munaligned-access -O0
> -emit-llvm -S test.c -o test.s
>
> CMD2: arm-none-eabi-gcc -mcpu=cortex-r52 -mthumb  -mno-unaligned-access
> -O0 -emit-llvm -S test.c -o test.s
>
>
>
> *Why does LLVM think it's a one-byte-aligned access? I think it makes more
> sense to access the number of aligned based on the type of the array
> element to which the array pointer points*
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200428/b7bed534/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 2815 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200428/b7bed534/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 14848 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200428/b7bed534/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 4289 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200428/b7bed534/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 3170 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200428/b7bed534/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image005.png
Type: image/png
Size: 3134 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200428/b7bed534/attachment-0004.png>


More information about the llvm-dev mailing list