similar to: TBAA metadata

Hi Duncan, I am hoping to remove the support for the old TBAA format soon. You should be able to switch to the new format by replacing MDNode *AliasTag = MDHelper.createTBAANode(TreeName, getTBAARoot()); with MDNode *AliasType = MDHelper.createTBAAScalarTypeNode(TreeName, getTBAARoot()); MDNode *AliasTag = MDHelper.createTBAAStructTagNode(AliasType, AliasType, 0) Also replacing

Our frontend can guarantee that loads from globals are rematerializable and do not alias with any stores in any function in the given module. We'd like the optimization passes (and ideally the register allocator as well) to be able to use this fact. The globals are not constant "forever" but are constant during the calling of any given function in the module. There seem 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

I am using llvm-2.6. In the online documentation, the signature is GlobalVariable::GlobalVariable ( const Type * Ty, bool isConstant, LinkageTypes Linkage, Constant * Initializer = 0, const Twine & Name = "", bool ThreadLocal = false, unsigned AddressSpace = 0 ) the link to the documenation is

> On Dec 1, 2014, at 3:44 PM, Philip Reames <listmail at philipreames.com> wrote: > > (Spawning a separate subthread off the 'Optimization hints for "constant" loads' discussion for a related question. ) > > Looking at TBAA again, I was reminded that TBAA also contains a third field which indicates that "meaning pointsToConstantMemory should return

Hi, It was a while now since I first asked about TBAA, and I am now getting back to this, trying to understand TBAA as it seems that the issue I described earlier originally in this thread is still one of many "TODO"s in CGExpr.cpp (http://lists.llvm.org/pipermail/llvm-dev/2018-September/126290.html). I would like to help on this to the best of my abilities, but I'm not quite

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 nodes !"A" and !"B" (as in > >

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

The following code snippet taken from StackColoring::remapInstructions clears a mem operand if it can't guarantee whether the memoperand's underlying value aliases with the merged allocas: // Update the MachineMemOperand to use the new alloca. 522 for (MachineInstr::mmo_iterator MM = I->memoperands_begin(), .... // Climb up and find the original alloca. 532 V =

On 22-Jul-08, at 1:22 PM, Dan Gohman wrote: > On Jul 21, 2008, at 3:51 PM, Stefanus Du Toit wrote: >> - build a custom alias analysis pass that indicates that these loads >> never alias with any stores in a given function >> - declare these globals as external constants within the module > > If you can convince yourself that no interprocedural optimization > will ever

2 new warnings in llvm: /Volumes/mrs5/net/llvm/llvm/lib/AsmParser/LLParser.cpp: In member function 'bool llvm::LLParser::ParseGlobal(const std::string&, const char*, unsigned int, bool, unsigned int)': /Volumes/mrs5/net/llvm/llvm/lib/AsmParser/LLParser.cpp:446: warning: 'IsConstant' may be used uninitialized in this function

A new warning: /Volumes/mrs5/net/llvm/llvm/lib/AsmParser/LLParser.cpp: In member function 'bool llvm::LLParser::ParseGlobal(const std::string&, const char*, unsigned int, bool, unsigned int)': /Volumes/mrs5/net/llvm/llvm/lib/AsmParser/LLParser.cpp:448: warning: 'IsConstant' may be used uninitialized in this function

Hi Tanya, I see the following warnings when building. I'm not sure how to fix any of them. The last one looks like it might be serious (seems like a job for Chris). llvm[1]: Compiling Path.cpp for Release build In file included from Path.cpp:270: Unix/Path.inc: In member function ‘bool llvm::sys::Path::eraseFromDisk(bool, std::string*) const’: Unix/Path.inc:661: warning: ignoring return

Hi Good day. For the following function local static constant array: static const __attribute__((used)) __attribute__((section("data"))) void *codetable[] = { &&RETURN, &&INCREMENT, &&DECREMENT, &&DOUBLE, &&SWAPWORD}; I have the following in the LLVM IR. @sampleCode.codetable = internal global [5 x i8*] [i8* blockaddress(@sampleCode, %19), i8*

On Jul 21, 2008, at 3:51 PM, Stefanus Du Toit wrote: > Our frontend can guarantee that loads from globals are > rematerializable and do not alias with any stores in any function in > the given module. We'd like the optimization passes (and ideally the > register allocator as well) to be able to use this fact. The globals > are not constant "forever" but are constant

This is the email I sent last week. ---------- Forwarded message ---------- From: Akira Hatanaka <ahatanak at gmail.com> Date: Wed, May 8, 2013 at 7:04 PM Subject: [PATCH] Minor fix to StackColoring to avoid needlessly clearing mem operands. To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> The following code snippet taken from StackColoring::remapInstructions clears a mem

Hi Akira, did anything happen with this patch? Ciao, Duncan. On 09/05/13 04:04, Akira Hatanaka wrote: > The following code snippet taken from StackColoring::remapInstructions clears a > mem operand if it can't guarantee whether the memoperand's underlying value > aliases with the merged allocas: > > // Update the MachineMemOperand to use the new alloca. > 522

I was reading the code in AliasAnalysis.cpp and happened to notice what looks like a bug. See the line marked by '*' below: AliasAnalysis::ModRefResult AliasAnalysis::getModRefInfo(const VAArgInst *V, const Location &Loc) { // If the va_arg address cannot alias the pointer in question, then the // specified memory cannot be accessed by the va_arg. if (!alias(getLocation(V),

I'm looking at how to optimize IR which contains reads from a field which is known to be initialized exactly once. I've got an idea on how to approach this, but wanted to see if others have alternate ideas or similar problems which might spark discussion. It feels like there's a potentially generally useful optimization hint here if we can generalize it sufficiently without

The patch LGTM. The StackColoring patch is still too conservative and I am consulting with Jakob and Andy about possible solutions. On May 13, 2013, at 10:33 AM, Akira Hatanaka <ahatanak at gmail.com> wrote: > This is the email I sent last week. > > ---------- Forwarded message ---------- > From: Akira Hatanaka <ahatanak at gmail.com> > Date: Wed, May 8, 2013 at 7:04