search for: kosarev

...be based on overlap of {OffsetInBase, BaseTag.getSize} and {SubobjecTag.getOffset(), SubobjectTag.getSize()} I am not sure if the same holds for the 'GenericTag'. Do you think that would cause other 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 >...

...e way we describe scalar accesses. To provide some background on importance of this matter, SROA and passing flattened parameters/returning values in clang together produce 75% of all undecorated loads and 90% if all undecorated stores on the LLVM code base under -O1. On 31/10/17 10:44, Ivan Kosarev wrote: > In short, the problem with !tbaa.struct is that in most cases it > cannot be converted to !tbaa. For transformations like SROA this means > they cannot propagate !tbaa.struct tags for aggregate-accessing > instructions like memcpy() calls to the resulting loads and stores. &...

On 02/11/17 05:54, Hal Finkel wrote: > > On 10/31/2017 05:02 AM, Ivan Kosarev wrote: >> To clarify further, what this paper proposes is to use !tbaa for all >> kinds of accesses, including aggregate ones, so we don't need to >> bother trying to convert them when an aggregate access becomes a >> series of scalar accesses or vice versa. As I said...

...n most cases it cannot be converted to !tbaa. For transformations like SROA this means they cannot propagate !tbaa.struct tags for aggregate-accessing instructions like memcpy() calls to the resulting loads and stores. On 31/10/17 05:11, Hal Finkel wrote: > > On 10/18/2017 05:49 AM, Ivan Kosarev via llvm-dev wrote: >> Hello, >> >> The motivation behind this proposal is to make it possible to >> propagate TBAA information through scalarizing transformations, >> such as SROA, that rewrite accesses to aggregates, e.g., memcpy() >> calls, into accesses to sc...

Do you have a formal description of your approach with examples? I have a bit of trouble visualizing exactly what your approach does. On Mon, Aug 14, 2017 at 9:58 AM, Ivan A. Kosarev via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hello Steven, Hal and Daniel, > > Thanks a lot for your discussion; it really helps with summarizing current > TBAA issues and ways to resolve them. > > Do you guys know anything of the current status of the proposed chang...

Hi Ivan, On 2019-01-18 10:15, Ivan Kosarev wrote: > IIRC, there were proposals/attempts to represent accesses to array > elements as accesses to their first elements, which can technically be > encoded with the current TBAA format and thus may work as an > incremental improvement on top of the existing TBAA machinery you are...

On Sun, Aug 20, 2017 at 8:54 AM, Ivan A. Kosarev via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hello Daniel, > > > The problem with the way you are trying to show this is that > > there are many ways to prove no-alias, and TBAA is one of them. > > The reason i stare at dump files and debug info is precisely to...

On 31/10/17 01:48, Hal Finkel wrote: > On 10/30/2017 04:57 PM, Ivan Kosarev via llvm-dev wrote: >> Hello, >> >> Consider these two TBAA access tags: >> >> !1 = !{!5, !5, i64 0} >> !3 = !{!7, !7, i64 0} >> >> !5 = !{!"A", !9} >> !7 = !{!"B", !9} > > I'd find this email less confusing if you&...

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

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

...{ int i; } *x; > > 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" >&gt...

...gt;> not click links or open attachments unless you recognize the sender >> and know the content is safe.  If you suspect potential phishing or >> spam email, report it to ReportSpam at accesssoftek.com >> >> Hi Ivan, >> >> >> On 2019-01-18 10:15, Ivan Kosarev wrote: >>> IIRC, there were proposals/attempts to represent accesses to array >>> elements as accesses to their first elements, which can technically be >>> encoded with the current TBAA format and thus may work as an >>> incremental improvement on top of the exi...

...ss 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 <dberlin at dberlin.org> wrote: > > > On Sat, Aug 19, 2017 at 6:29 AM, Ivan A. Kosarev via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Daniel, Hal, >> >> I'm trying to figure out what we would need to do in terms of the current >> approach, accepting its limitations, > > > We don't have to accept the limitations? > We a...

On Sat, Aug 19, 2017 at 1:04 PM, Ivan A. Kosarev via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Daniel, > > >> the type of (*x) is not compatible with the type of (*b) or, > >> recursively, type of b->i. Similarly, the type of (*b) is not > >> compatible with (*x) or, recursively, x->i. > ......

On Sun, Aug 20, 2017 at 2:47 AM, Ivan A. Kosarev via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hello Daniel, > > >>>> the type of (*x) is not compatible with the type of (*b) or, > >>>> recursively, type of b->i. Similarly, the type of (*b) is > >>>> not compatible with (*x) or, r...

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:

Hi Ivan, On 2019-01-17 18:09, Ivan Kosarev wrote: > Hello, Jonas, > > > It seems that when the struct member is an array, the base type > > becomes the element type. This is simply unhandled still in > > CodeGenTBAA ("TODO"). My question then is if it would be > > possible to instead create the DAG no...

Hello, The motivation behind this proposal is to make it possible to propagate TBAA information through scalarizing transformations, such as SROA, that rewrite accesses to aggregates, e.g., memcpy() calls, into accesses to scalars, that is, load and store instructions. Currently, we decorate instructions that initialize and copy aggregates with !tbaa.struct tags that generally cannot be

Hello, I'm trying to get the whole picture of what we are doing in terms of alias analysis in LLVM. Being new to this I may be missing some well known things so my apologies if I seem to ask obvious things. There are lots of questions arise in my head as I read related bug reports, sources and documentation, of which looks to be the most simple is, Why the current TBAA implementation

On 08/20/2017 11:22 AM, Daniel Berlin via llvm-dev wrote: > Sorry, hit send early. > > > On Sun, Aug 20, 2017 at 9:16 AM, Daniel Berlin <dberlin at dberlin.org > <mailto:dberlin at dberlin.org>> wrote: > > > > On Sun, Aug 20, 2017 at 8:54 AM, Ivan A. Kosarev via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > Hello Daniel, > > > The problem with the way you are trying to show this is that > > there are many ways to prove no-alias, and TBAA is one of t...