[llvm-dev] Aliasing and forwarding optimization
Venkataramanan Kumar via llvm-dev
llvm-dev at lists.llvm.org
Fri Jun 19 09:19:53 PDT 2020
Hi Hiroshi,
On Fri, 19 Jun 2020 at 21:20, Hiroshi Yamauchi <yamauchi at google.com> wrote:
> If you see the LLVM IR output, the second line is lowered into a
> load/store of an int. Maybe that's why.
>
%7 = load i32, i32* %5, align 4, !dbg !39, !tbaa !40
store i32 %7, i32* %6, align 4, !dbg !39, !tbaa !40
yes the structure copy seem to happen as integer type load and store.
Sometimes I also see structure type bitcasted to integer pointer type and
then load/store happens in integer type.
Alias is conservatively saying may-alias?
regards,
venkat.
>
> https://godbolt.org/z/u3VyAM
>
> I'm not sure what the strict aliasing rules say about this, though.
>
> HTH
>
> On Thu, Jun 18, 2020 at 10:16 PM Venkataramanan Kumar via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>>
>> ----Snip--
>> struct st1{
>> int a;
>> };
>> struct st2{
>> int b;
>> };
>> struct st {
>> struct st1 obj1;
>> struct st2 obj2;
>> }Obj;
>>
>> int test1(struct st1 * ptr1 , struct st2 * ptr2, struct st2 *ptr3) {
>> ptr1->a = 10;
>> *ptr3 = *ptr2;
>> return ptr1->a;
>> }
>> --Snip---
>>
>> For the above case GCC is able to store forward the value 10 to the
>> return place.
>> LLVM is not doing this.
>> GCC
>> https://godbolt.org/z/FCjCXy
>> LLVM
>> https://godbolt.org/z/TFgnig
>>
>> My understanding is that under strict aliasing rules accessing objects of
>> different types don't alias.
>> In this case we are accessing "struct st2" object and "int" type
>> object. so aliasing should not prevent the forwarding of store 10 to the
>> return place .
>>
>> Can someone please clarify this?
>>
>>
>> regards,
>> Venkat.
>>
>> :
>> _______________________________________________
>> 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/20200619/cb74662e/attachment.html>
More information about the llvm-dev
mailing list