Panyuntao(Compiler) via llvm-dev
2020-Apr-26 12:55 UTC
[llvm-dev] Is this a bug or is llvm processing conservative?
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. [cid:image001.png at 01D61C07.2E95DB10] 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. [cid:image002.png at 01D61C08.6DC76AF0] 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. [cid:image003.png at 01D61C09.E2D82DB0] CMD: llc -mattr=-strict-align test.ll If the CPU support non-aligned access, It's a normal four-byte access. [cid:image004.png at 01D61C0A.F65032B0] 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 [cid:image005.png at 01D61C0B.34493800] 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200426/0509fcb4/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 2815 bytes Desc: image001.png URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200426/0509fcb4/attachment-0005.png> -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 14848 bytes Desc: image002.png URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200426/0509fcb4/attachment-0006.png> -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.png Type: image/png Size: 4289 bytes Desc: image003.png URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200426/0509fcb4/attachment-0007.png> -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.png Type: image/png Size: 3170 bytes Desc: image004.png URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200426/0509fcb4/attachment-0008.png> -------------- next part -------------- A non-text attachment was scrubbed... Name: image005.png Type: image/png Size: 3134 bytes Desc: image005.png URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200426/0509fcb4/attachment-0009.png> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: test.c URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200426/0509fcb4/attachment-0001.c> -------------- next part -------------- A non-text attachment was scrubbed... Name: test.ll Type: application/octet-stream Size: 1763 bytes Desc: test.ll URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200426/0509fcb4/attachment-0005.obj> -------------- next part -------------- A non-text attachment was scrubbed... Name: llvm-align-access.s Type: application/octet-stream Size: 1925 bytes Desc: llvm-align-access.s URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200426/0509fcb4/attachment-0006.obj> -------------- next part -------------- A non-text attachment was scrubbed... Name: llvm-no-align-access.s Type: application/octet-stream Size: 1866 bytes Desc: llvm-no-align-access.s URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200426/0509fcb4/attachment-0007.obj> -------------- next part -------------- A non-text attachment was scrubbed... Name: gcc-no-unaligned-access.s Type: application/octet-stream Size: 882 bytes Desc: gcc-no-unaligned-access.s URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200426/0509fcb4/attachment-0008.obj> -------------- next part -------------- A non-text attachment was scrubbed... Name: gcc-unaligned-access.s Type: application/octet-stream Size: 882 bytes Desc: gcc-unaligned-access.s URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200426/0509fcb4/attachment-0009.obj>
Hiroshi Yamauchi via llvm-dev
2020-Apr-28 16:56 UTC
[llvm-dev] Is this a bug or is llvm processing conservative?
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>