similar to: RFC: Drop support for old style scalar TBAA

Seems like a nice cleanup to me! > On 2016-Nov-07, at 13:01, Sanjoy Das via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi all, > > I want to clarify / emphasize two things based on an off-list > conversation: > > - The bitcode and IR parser both auto upgrade old style TBAA to the > newer TBAA struct tags. Shouldn't we drop the textual IR

Hi I am upgrading my clang fork from 5.0 to 6.0 and I am hit by this error: Access type node must be a valid scalar type %4 = load %"struct.Foo::p.test1::"*, %"struct.Foo::p.test1::"** %_param.addr, align 8, !tbaa !16 !16 = !{!15, !15, i64 0} !15 = !{!"p.test1::", !13, i64 0, !13, i64 8} It looks like !16 is referencing !15, which is a struct. !13 is !13 =

On Mon, Aug 12, 2013 at 1:37 PM, Michele Scandale < michele.scandale at gmail.com> wrote: > > I don't think you need to change any of the existing MDNode's or AA > passes. TBAA adds metadata because that information isn't in the IR > itself, but your IR has the address spaces. > > > > Shouldn't the address space of the pointer and some additional

On Mon, Aug 12, 2013 at 6:03 AM, Michele Scandale < michele.scandale at gmail.com> wrote: > On 08/12/2013 12:44 AM, Michele Scandale wrote: > > The idea is to extend the BasicAliasAnalysis to use addrspace modifier + > target > > information to decide aliasing based on physical address spaces and > create a > > "MemorySpaceAliasAnalysis" for those case

On 08/12/2013 12:44 AM, Michele Scandale wrote: > The idea is to extend the BasicAliasAnalysis to use addrspace modifier + target > information to decide aliasing based on physical address spaces and create a > "MemorySpaceAliasAnalysis" for those case where source language level > information may help, right? I was looking to the AliasAnalysis infrastructure and TBAA

On Mon, Aug 12, 2013 at 8:24 AM, Michele Scandale < michele.scandale at gmail.com> wrote: > On 08/12/2013 02:02 PM, Justin Holewinski wrote: > > On Mon, Aug 12, 2013 at 6:03 AM, Michele Scandale < > michele.scandale at gmail.com > > <mailto:michele.scandale at gmail.com>> wrote: > > > > On 08/12/2013 12:44 AM, Michele Scandale wrote: > >

On 08/12/2013 02:02 PM, Justin Holewinski wrote: > On Mon, Aug 12, 2013 at 6:03 AM, Michele Scandale <michele.scandale at gmail.com > <mailto:michele.scandale at gmail.com>> wrote: > > On 08/12/2013 12:44 AM, Michele Scandale wrote: > > The idea is to extend the BasicAliasAnalysis to use addrspace modifier + > target > > information to decide

On 08/11/2013 10:38 PM, Justin Holewinski wrote: > On Sun, Aug 11, 2013 at 5:49 AM, Michele Scandale <michele.scandale at gmail.com > <mailto:michele.scandale at gmail.com>> wrote: > > On 08/11/2013 08:41 AM, Micah Villmow wrote: > > How about this as a solution. > > > > Add one hook into TargetInstrInfo, and one into TargetISelLowering.

On 08/12/2013 02:34 PM, Justin Holewinski wrote: > On Mon, Aug 12, 2013 at 8:24 AM, Michele Scandale <michele.scandale at gmail.com > <mailto:michele.scandale at gmail.com>> wrote: > > On 08/12/2013 02:02 PM, Justin Holewinski wrote: > > On Mon, Aug 12, 2013 at 6:03 AM, Michele Scandale > <michele.scandale at gmail.com <mailto:michele.scandale at

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,

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

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

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

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

Hi, I work on DDC, the compiler of a research Haskell dialect, Disciple (disciple.ouroborus.net (http://disciple.ouroborus.net)). We are looking to make use of LLVM's type-based alias analysis metadata to encode non-aliasing information between variables. We have found that the tbaa structure is somewhat limited in its expressivity. In particular we couldn't encode intransitive

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,