search for: ikosarev

Daniel, > This is an aggregate type that includes a type compatible > with the effective type of the object. In particular, > x->i is an lvalue expression of type "int" > b->a is an lvalue expression of type "struct A" > "struct A" is an aggregate type that includes "int" among > its members. > Therefore, the b->a

...ther problems ? Thanks, Jeroen Dobbelaere > -----Original Message----- > From: Ivan Kosarev <ivan at kosarev.info> > Sent: Wednesday, June 5, 2019 12:25 > To: Jeroen Dobbelaere <Jeroen.Dobbelaere at synopsys.com>; llvm- > dev at lists.llvm.org > Cc: Ivan Kosarev <ikosarev at accesssoftek.com> > Subject: Re: [llvm-dev] llvm-ir: TBAA and struct copies > > Hello Jeroen, > > AFAIR, with the current TBAA format the access type shall never be an > aggregate, so the !10 node looks suspicious. > > Tried to reproduce this on 362464 with that sam...

"then gcc does the right thing in both cases." There is no way it would ever affect execution semantics except through deletion, so ... On Sat, Aug 19, 2017 at 10:54 AM, Ivan A. Kosarev <ikosarev at accesssoftek.com > wrote: > Can you share the snippets you use? > > Reloading x->i may affect performance, but not necessarily execution > semantics. Sure > So if it is not required to reload the value (what I think is true), then > gcc does the right thing in both c...

...t; > b->a > x->i > Do you believe the answer changes if you had struct A *x instead of struct X *x? If so, why? On Sat, Aug 19, 2017 at 10:58 AM, Daniel Berlin <dberlin at dberlin.org> wrote: > > > On Sat, Aug 19, 2017 at 10:48 AM, Ivan A. Kosarev < > ikosarev at accesssoftek.com> wrote: > >> Daniel, >> >> > This is an aggregate type that includes a type compatible >> > with the effective type of the object. In particular, >> > x->i is an lvalue expression of type "int" >> > b->a is a...

(and note: It's not clear GCC agrees with my interpretation. I can get it to seem to answer both ways. Depending on what i do, and looking at optimizer dumps, i can get it to ignore the access to x->i, and assume it has no effect on b->a, *and* get it to assume it does, and cause reloads of x->i) +Richard in case he has any thoughts. On Sat, Aug 19, 2017 at 9:00 AM, Daniel Berlin

> -----Original Message----- > From: meinersbur at googlemail.com [mailto:meinersbur at googlemail.com] On > Behalf Of Michael Kruse > Sent: Wednesday, October 18, 2017 1:18 PM > To: Song, Ruiling <ruiling.song at intel.com> > Cc: Michael Kruse <llvm at meinersbur.de>; llvm-dev at lists.llvm.org > Subject: Re: Possible bug of Alias Analysis? > > 2017-10-18

Hi, I have a question about the current definition of TBAA (See [1]). In the LLVM-IR code that we produce, we generate load/stores of struct types. (See [2] and [3] for a godbolt example showing the issue) For following c-alike code: struct S { int dummy; short e, f; } x,y; struct S* p = &x; int foobar() { x.f=42; *p=y; //**** struct copy return x.f; } We produce: