search for: md_tbaa

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

...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 implementation details. The only metadata kind currently supported is the MD_tbaa, in fact AliasAnalysis::Location has exactly one field for the TBAA tag. I think that deciding the aliasing based on the address space should happen before considering type informations, so the TBAA extension would not be a general solution. Actually how a new independent alias analysis based on...

...aces and > create a > > "MemorySpaceAliasAnalysis" for those case where source language level > > information may help, right? > > I was looking to the AliasAnalysis infrastructure and TBAA implementation > details. The only metadata kind currently supported is the MD_tbaa, in fact > AliasAnalysis::Location has exactly one field for the TBAA tag. > > I think that deciding the aliasing based on the address space should happen > before considering type informations, so the TBAA extension would not be a > general solution. > I could see this going eit...

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

...gt; metadata representation and don't have an intermediate IR or > bitcode parsing step that would have auto-upgraded the IR. In this > case, the quickest way to keep your frontend working with the new > representation is to change > > I->setMetadata(LLVMContext::MD_tbaa, MD); > > to > > I->setMetadata(LLVMContext::MD_tbaa, llvm::UpgradeTBAANode(*MD)); > > llvm::UpgradeTBAA is present on tip-of-tree. If your version of > LLVM is too old to have that utility then copy/pasting it in from > tip-of-tree into your code base sho...

...ate a > > "MemorySpaceAliasAnalysis" for those case where source language level > > information may help, right? > > I was looking to the AliasAnalysis infrastructure and TBAA implementation > details. The only metadata kind currently supported is the MD_tbaa, in fact > AliasAnalysis::Location has exactly one field for the TBAA tag. > > I think that deciding the aliasing based on the address space should happen > before considering type informations, so the TBAA extension would not be a > general solution. > > &gt...

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.

...orySpaceAliasAnalysis" for those case where source language > level > > > information may help, right? > > > > I was looking to the AliasAnalysis infrastructure and TBAA > implementation > > details. The only metadata kind currently supported is the MD_tbaa, > in fact > > AliasAnalysis::Location has exactly one field for the TBAA tag. > > > > I think that deciding the aliasing based on the address space should > happen > > before considering type informations, so the TBAA extension would > not be a > &gt...

...ceAliasAnalysis" for those case where source language level > > > information may help, right? > > > > I was looking to the AliasAnalysis infrastructure and TBAA implementation > > details. The only metadata kind currently supported is the MD_tbaa, in > fact > > AliasAnalysis::Location has exactly one field for the TBAA tag. > > > > I think that deciding the aliasing based on the address space should > happen > > before considering type informations, so the TBAA extension woul...

...if the struct object is from a derived class; iterating over the struct again, it looks like the vtable ptr is tangled even deeper within the object: %class.Base.base = type <{i32 (...)**, i32 }> i32 I looked at the ThreadSanitizer.cpp pass for inspiration, and it seems they are also using MD_tbaa as hints for whether a load/store isVTableAccess(), but doesn't need the Value. Maybe MDNode metadata could be of use here? TLDR: How can I leverage a Value that is of StructType generated from a C++ object to get its vtable ptr in LLVM to use as a Value for a to-be-inserted function call?? T...

...;MemorySpaceAliasAnalysis" for those case where source language level >>>> information may help, right? >>> >>> I was looking to the AliasAnalysis infrastructure and TBAA implementation >>> details. The only metadata kind currently supported is the MD_tbaa, in >> fact >>> AliasAnalysis::Location has exactly one field for the TBAA tag. >>> >>> I think that deciding the aliasing based on the address space should >> happen >>> before considering type informations, so the TBAA extension woul...

before inlining all 20005 after inlining somewhere here changed made it NoAlias after Global Variable Optimizer 20014 20373 20255 20372 20254 before GVN 19993 20011 19991 20010 20030 It appears that TBAA metadata certainly changed after inlining and subsequent passes. I have attached the .bc file. I think I will try to dump out more TBAA metadata between passes. The method in

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 =