llvm dev - Jun 2020 - Aliasing and forwarding optimization

----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.

:
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200619/f907614a/attachment.html>

If you see the LLVM IR output, the second line is lowered into a load/store
of an int. Maybe that's why.

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/849a475d/attachment.html>

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>