similar to: [LLVMdev] bending the limits of tbaa metadata

Hi all, A while ago there was a discussion on changing the current "set of trees" representation of TBAA metadata to be more expressive, prompted by the need to support C structs. Dan Gohman also talked about the issue here: http://llvm.org/devmtg/2012-11/Gohman-AliasAnalysis.pdf. It was suggested that the trees be replaced by a type DAG then. While working on this compiler

geovanisouza92 at gmail.com wrote: > I'm trying create a new programming language, and I want that it have > Unicode support (support for read and manipulate rightly the source-code and > string literals). LLVM IR iteself only supports one string ty, which is an array of i8 (8 bit integers). In your compile you can use utf-8 and any utf8 string literal can be stored in an i8 array

On 07/03/2013, at 1:45 AM, Daniel Berlin <dberlin at dberlin.org> wrote: > On Wed, Mar 6, 2013 at 4:23 AM, Tran Ma <tranma at cse.unsw.edu.au> wrote: >> It was derived from what I read in Dan Gohman's slides about one of the >> possible forms a type DAG could take. Your forest is what we should get in >> the current tree representation (I believe), so when we

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

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/2017 05:49 AM, Ivan Kosarev via llvm-dev wrote: >> Hello,

Aloha all, I have an adjacency matrix for an acyclic digraph that contains transitive relations, e.g. (u,v), (v,w), (u,w). I want a DAG with only intransitive relations. Can someone point me to an R function that will take my adjacency matrix and give me back one with only intransitive relations? In the example, I'd like to get rid of (u,w) and keep (u,v) and (v,w). All the best, Tom --

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 type of the aggregate itself and only

Hi Jun, On 27/09/12 08:02, Jun Koi wrote: > 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

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). Ciao, Duncan. > 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

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

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

On Thu, Sep 27, 2012 at 3:31 PM, Duncan Sands <baldrick at free.fr> wrote: > Hi Jun, > > > On 27/09/12 08:02, Jun Koi wrote: >> >> 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

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,

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

Hi Yi, I didn't get a chance to run your code. But from the debug information you posted about tbaa alias analysis: Alias Set Tracker: 1 alias sets for 7 pointer values. AliasSet[0x207f860, 7] may alias, Mod/Ref Pointers: (i32* %1, 4), (i32* %x, 4), (i32** %p, 8), (i32** %q, 8), (float* %z, 4), (float** %t, 8), (i32* %2, 4) I guess it is because of the way how TBAA alias analysis treats

On Jan 27, 2012, at 4:15 PM, Maurice Marks wrote: > Our application generates 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

Hi Manman, thanks for the heads up. I looked into what it would take to produce full struct TBAA metadata from the GCC aliasing info (GCC has aliasing info for struct types, in fact for any type), but it looks kind of tricky. The problem is the "offset" field, which doesn't exist in GCC. In GCC the aliasing information forms a DAG, with a node for each type, plus a special root

On Fri, 2012-01-27 at 16:46 -0800, Dan Gohman wrote: > On Jan 27, 2012, at 4:15 PM, Maurice Marks wrote: > > > Our application generates 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

On Mon, Dec 5, 2011 at 6:08 PM, <ggan at codeaurora.org> wrote: > Hi Yi, > > I didn't get a chance to run your code. But from the debug information you > posted about tbaa alias analysis: > > Alias Set Tracker: 1 alias sets for 7 pointer values. >  AliasSet[0x207f860, 7] may alias, Mod/Ref   Pointers: (i32* %1, 4), > (i32* %x, 4), (i32** %p, 8), (i32** %q, 8),

Thanks for the explanation Sanjoy! Another question I have is: are there are any passes that invalidate or make the TBAA analysis information less precise? I noticed that TBAA is only run once, early on in the pass ordering for O1 through O3. My thinking is that if a pass that duplicates code is run, the analysis info may not have data for the result of the new load/stores. A solution might be