search for: tbaa

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

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 31/10/17 05:11, Hal Finkel wrote: > > On 10/18/201...

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, in most cases such conversions are not possible anyway, because !tbaa.struct tags do not refer to the...

...ign 2 %t.i = alloca [13 x i16], align 2 %u.i = alloca [13 x i16], align 2 %w.i = alloca [13 x i16], align 2 %e = alloca [13 x i16], align 2 %rnd = alloca %struct.LDPARMS, align 4 %outbuf = alloca [57 x i8], align 1 %du = alloca double, align 4 store double %d, double* %du, align 4, !tbaa !0 %rlast = getelementptr inbounds %struct.LDPARMS* %rnd, i32 0, i32 0 store i32 -1, i32* %rlast, align 4, !tbaa !3 %rndprc = getelementptr inbounds %struct.LDPARMS* %rnd, i32 0, i32 1 store i32 144, i32* %rndprc, align 4, !tbaa !3 %_result = getelementptr inbounds %struct._reent* %ptr, i...

I'm interested in what we can do about TBAA for loads that the compiler inserts when optimizing loads into smaller loads (e.g. what SROA does). I'm gonna set the stage by using a small C snippet, because I think C has the best-understood implementation of TBAA among the folks on the list. However, I was unable to actually come up with an...

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, in most cases >> such conversions are not possible anyway, because !...

hi, i have a simple code like below, in wich variable "aaa" does not alias to "bbb". i use TBAA to specify this, please see the code. then i ran this code thru LLVM optimization, and i expected that the second "store" instruction is eliminated. however, i am wrong: the second "store" instruction is still there after optimization. perhaps my TBAA setup is wrong somewhere?...

I was trying to add some stronger assertions in the verifier around !tbaa metadata when I ran into an ambiguity: I think the encoding of the metadata nodes are such that a given node can be interpreted as either a struct type node or a scalar tbaa node. I'd like a sanity check before I try to fix or work around this. Consider some IR that I got from running clang o...

...ates IR that is used to generate X86_64 code for a Jit. We noticed that code generated with llvm 3.0 is worse in some circumstances that it was with 2.9. I traced the differences to alias analysis differences. Our IR references data structures that have lots of derived pointers and we use extensive tbaa metadata to indicate which pointers dont alias. Some of this seemed to be getting ignored in 3.0. I found by using opt on our IR that the ordering of the basicaa and tbaa optimization passes made all the difference. Code in addInitialAliasAnalysisPasses() adds the tbaa pass then basicaa pass. From...

On Thu, Sep 20, 2012 at 5:18 PM, Duncan Sands <baldrick at free.fr> wrote: > Hi Jun, did you tell "opt" to make use of TBAA? Also, please give complete > IR > that people can use to reproduce, and instructions on how to reproduce (eg > how > to run opt). > actually, i am still confused on which options should be given to "opt" for it to use TBAA. any hint? of course, we can simply use -O3, bu...

...tend abided by the rules, there shouldn't be a problem. > > > My concerns are simply that whether designed this way or not, it ends up fairly inconsistent. > > For example, what would the plan be when a frontend does something like clang does now for C/C++ (generate type based TBAA), and also wants to do something like Filip is suggesting (which is also doable on C/C++ with simple frontend analysis)? There are two possible answers here, depending on the constraints: 1. The frontend author could unify them into one grand tree, like struct field TBAA does. 2. The frontend aut...

...there >> shouldn't be a problem. >> > > > My concerns are simply that whether designed this way or not, it ends up > fairly inconsistent. > > For example, what would the plan be when a frontend does something like > clang does now for C/C++ (generate type based TBAA), and also wants to do > something like Filip is suggesting (which is also doable on C/C++ with > simple frontend analysis)? > > > There are two possible answers here, depending on the constraints: > > 1. The frontend author could unify them into one grand tree, like struct &gt...

...ates IR that is used to generate X86_64 code for a Jit. We noticed that code generated with llvm 3.0 is worse in some circumstances that it was with 2.9. I traced the differences to alias analysis differences. Our IR references data structures that have lots of derived pointers and we use extensive tbaa metadata to indicate which pointers dont alias. Some of this seemed to be getting ignored in 3.0. I found by using opt on our IR that the ordering of the basicaa and tbaa optimization passes made all the difference. Code in addInitialAliasAnalysisPasses() adds the tbaa pass then basicaa pass. From...

In https://reviews.llvm.org/D26229 I've proposed dropping support for old style scalar TBAA metadata. Here is the proposed commit message: "We've had support for auto upgrading old style scalar TBAA access metadata into the "new" struct path aware TBAA metadata for 3 years now. The only way to actually generate old style TBAA was explicitly through the IRBuilder API....

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

...at I want? double f(double** p ) { double *__restrict__ x = p[0]; double *__restrict__ y = p[1]; double *__restrict__ z = p[2]; *x = 1; *y = *x + 2; *z = *x + 3; return *x+*y+*z; } define double @f(double** nocapture %p) nounwind uwtable { %1 = load double** %p, align 8, !tbaa !0 %2 = getelementptr inbounds double** %p, i64 1 %3 = load double** %2, align 8, !tbaa !0 %4 = getelementptr inbounds double** %p, i64 2 %5 = load double** %4, align 8, !tbaa !0 store double 1.000000e+00, double* %1, align 8, !tbaa !3 store double 3.000000e+00, double* %3, align 8, !tb...

I think we’re talking cross-purposes at this point. Let me try to step back and concisely restate what I’m trying to do: - I am writing a frontend for a high-level language and I emit LLVM IR. - I control the TBAA tree. I don’t use it to express the high-level language’s types, since that would make absolutely no sense. JavaScript doesn’t have types. But by the time my compiler is generating LLVM IR, it will have come up with meaningful constraints on aliasing and those constraints are naturally expressed...

...its IR. *IR before vectorization :*target datalayout = "e-m:e-p:32:32-f64:32:64-f80:32-n8:16:32-S128" target triple = "x86_64-pc-linux-gnu" ; Function Attrs: nounwind define void @foo(i32* nocapture readonly %a, i32* nocapture %sum) #0 { entry: %0 = load i32* %a, align 4, !tbaa !1 %arrayidx1 = getelementptr inbounds i32* %a, i32 1 %1 = load i32* %arrayidx1, align 4, !tbaa !1 %add = add nsw i32 %1, %0 %arrayidx2 = getelementptr inbounds i32* %a, i32 2 %2 = load i32* %arrayidx2, align 4, !tbaa !1 %add3 = add nsw i32 %add, %2 %arrayidx4 = getelementptr inbounds...

TBAA MDNodes should describe the type hierarchy (with struct-path aware TBAA, it is a type DAG). It sounds okay to me to add !tbaa.call to function calls to describe which fields of the type system the call is touching. One example can be !tbaa.call {read a list of tag nodes, write a list of tag nodes}....

On Oct 11, 2013, at 12:16 AM, Daniel Berlin <dberlin at dberlin.org> wrote: > There are two possible answers here, depending on the constraints: > > 1. The frontend author could unify them into one grand tree, like struct field TBAA does. > > I would be impressed if you could unify the output of something like andersens, and something like the current nested TBAA structure, without massive loss of precision. To clarify, I have no desire (and I think it would be completely the wrong approach) to represent "points-t...