[llvm-dev] InstCombine GEP

[Nema, Ashutosh via llvm-dev]

Thanks Nuno & Sanjoy for the inputs.

As you mentioned the flattened GEPs should neither help nor hinder AA & SROA.
It's good to keep type based GEPs. I'll make the change and submit for review.

Regards,
Ashutosh

-----Original Message-----
From: Nuno Lopes [mailto:nunoplopes at sapo.pt] 
Sent: Thursday, August 10, 2017 11:28 PM
To: 'Sanjoy Das' <sanjoy at google.com>; Nema, Ashutosh <Ashutosh.Nema at amd.com>; 'llvm-dev' <llvm-dev at lists.llvm.org>
Subject: RE: [llvm-dev] InstCombine GEP

> On Thu, Aug 10, 2017 at 12:22 AM, Nema, Ashutosh via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>> I’m not sure how transforming GEP offset to i8 type will help alias 
>> analysis & SROA for the mentioned test case.
>
> It should neither help nor hinder AA or SROA -- the two GEPs (the complex one and the simple one) are equivalent.  > Since memory isn't typed in LLVM, having the GEP in terms of %struct.ABC does not provide any extra information.

Memory is somewhat typed, since if you store something with a type and load the same location with a different type that's not valid (let's call it poison).

Also, BasicAA has the following rule, with constants c1 and c2, and arbitrary values x, y:
a[x][c1] no-alias a[y][c2] if:
the distance between c1 and c2 is sufficient to guarantee that the accesses will be disjoint due to ending up in different array slots.
For this rule it's important to know what's the size of each array element. This information is lost if GEPs are flattened.

But I agree that LLVM itself doesn't exploit types for AA extensively. For example, a pointer based in a struct field may alias another field of the same struct, even if at C/C++ level that's probably not allowed.

Nuno