[Bug tree-optimization/102162] Byte-wise access optimized away at -O1 and above

2021-09-01 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102162 --- Comment #10 from Andrew Pinski --- So I looked into this a little bit and it works on aarch64 with -O1 -mstrict-align but if you remove -mstrict-align we get an unaligned access which I think it is expected. The gimple level is the same in

[Bug tree-optimization/102162] Byte-wise access optimized away at -O1 and above

2021-09-01 Thread deller at gmx dot de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102162 --- Comment #9 from deller at gmx dot de --- On 9/1/21 11:25 PM, deller at gmx dot de wrote: > The "ldh" loads only the first two bytes, and extends it into the upper 32bits > with "extrw,s". > So, only 16bits instead of 32bits are loaded from

[Bug tree-optimization/102162] Byte-wise access optimized away at -O1 and above

2021-09-01 Thread deller at gmx dot de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102162 --- Comment #8 from deller at gmx dot de --- On 9/1/21 11:19 PM, dave.anglin at bell dot net wrote: >> I think the problem with your testcase is, that the compiler doesn't know the >> alignment of the parameter "p" in your f_unaligned()

[Bug tree-optimization/102162] Byte-wise access optimized away at -O1 and above

2021-09-01 Thread dave.anglin at bell dot net via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102162 --- Comment #7 from dave.anglin at bell dot net --- On 2021-09-01 4:52 p.m., deller at gmx dot de wrote: > I think the problem with your testcase is, that the compiler doesn't know the > alignment of the parameter "p" in your f_unaligned()

[Bug tree-optimization/102162] Byte-wise access optimized away at -O1 and above

2021-09-01 Thread deller at gmx dot de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102162 --- Comment #6 from deller at gmx dot de --- > So, it seems the __aligned__ attribute is ignored: > extern u32 output_len __attribute__((__aligned__(1))); I think the aligned attribute is not relevant here. Even u32 output_len; will

[Bug tree-optimization/102162] Byte-wise access optimized away at -O1 and above

2021-09-01 Thread dave.anglin at bell dot net via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102162 --- Comment #5 from dave.anglin at bell dot net --- On 2021-09-01 4:52 p.m., deller at gmx dot de wrote: > I think the problem with your testcase is, that the compiler doesn't know the > alignment of the parameter "p" in your f_unaligned()

[Bug tree-optimization/102162] Byte-wise access optimized away at -O1 and above

2021-09-01 Thread dave.anglin at bell dot net via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102162 --- Comment #4 from dave.anglin at bell dot net --- On 2021-09-01 4:14 p.m., arnd at linaro dot org wrote: > Any idea what the difference is between the working version and your broken > one? Not really.  My original test case worked as well. 

[Bug tree-optimization/102162] Byte-wise access optimized away at -O1 and above

2021-09-01 Thread deller at gmx dot de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102162 --- Comment #3 from deller at gmx dot de --- Hi Arnd, I think the problem with your testcase is, that the compiler doesn't know the alignment of the parameter "p" in your f_unaligned() function. So it will generate byte-accesses. If you

[Bug tree-optimization/102162] Byte-wise access optimized away at -O1 and above

2021-09-01 Thread arnd at linaro dot org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102162 Arnd Bergmann changed: What|Removed |Added CC||arnd at linaro dot org --- Comment #2

[Bug tree-optimization/102162] Byte-wise access optimized away at -O1 and above

2021-09-01 Thread danglin at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102162 --- Comment #1 from John David Anglin --- Created attachment 51395 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51395=edit Second test case Changing the optimization of get_unaligned_le32 to 0 results in correct code generation. We