search for: vaarginst

Hi all, Would it be correct to say that the only instructions in LLVM IR that modify/access memory potentially are the following: (1) LoadInst : Ref (2) StoreInst : Mod (3) VAArgInst : Ref (?) (4) AllocaInst : Mod (5) MallocInst : Mod (6) FreeInst : Mod (7) CallInst : Mod/Ref ? Also, my earlier impression was that the GEP instruction only computes the effective address and does not modify/access any memory location. Is that true ? If I have missed other instructions that could...

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), Loc)) return NoModRef; // If the pointer is a pointer to constant memory, then it could not have been...

In the implementation of the AliasSetTracker, I see LoadInst, StoreInst, and VAArgInst are treated specially. Why aren't AtomicCmpXchgInst and AtomicRMWInst treated with similar care? Lumping together with other unknown instructions seems unnecessarily expensive in compile time. Preston -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://...

...details. I believe these methods describe whether memory is read/written in a way visible from the LLVM IR; I don't believe they'll take into account things like read/writes due to register spills created by the code generator. > (1) LoadInst : Ref > (2) StoreInst : Mod > (3) VAArgInst : Ref (?) > (4) AllocaInst : Mod > (5) MallocInst : Mod > (6) FreeInst : Mod > (7) CallInst : Mod/Ref ? > > Also, my earlier impression was that the GEP instruction only computes > the effective address and does not modify/access any memory location. > Is that true ? >...

...perienced by running the IR code at then end. E:\test>clang test.ll -o test.exe E:\test>test.exe values : n2 = 16, dna = 0, dnb = 10 n2, dna and dnb are respectively the three i32 variables. Does anyone know how to fix this? Alignment attribute on the variadic function do nothing and the VAArgInst does not support setAlignment() like the AllocaInstr. During my research, I found that when a VAArgInst is being lowered in SelectionDAG::expandVAARG(), the alignment information is retrieved from the va_arg SDNode and the lowering is wrong (in this case). The alignment is set in SelectionDAGBui...

Oh, no. I should have been more clear. The patch was not rejected, just lost in the daily shuffle. I already have my employer's approval to send this upstream, so I will prepare a patch against trunk this morning. > I proposed a similar patch to LLVM (left circular shift) around 10/2011. > > Parts of my patch did make it into trunk about a year after, but others > > did not.

...perienced by running the IR code at then end. E:\test>clang test.ll -o test.exe E:\test>test.exe values : n2 = 16, dna = 0, dnb = 10 n2, dna and dnb are respectively the three i32 variables. Does anyone know how to fix this? Alignment attribute on the variadic function do nothing and the VAArgInst does not support setAlignment() like the AllocaInstr. During my research, I found that when a VAArgInst is being lowered in SelectionDAG::expandVAARG(), the alignment information is retrieved from the va_arg SDNode and the lowering is wrong (in this case). The alignment is set in SelectionDAGBui...

On Monday, July 30, 2012 12:16 AM, Cameron McInally wrote: > Hey Andy, > > I proposed a similar patch to LLVM (left circular shift) around 10/2011. > Parts of my patch did make it into trunk about a year after, but others > did not. > > At that time, my solution was to add a binary operator to the IRBuilder, > since LCS fits in nicely with the other shift operators. But,

...8, Call , CallInst ) // Call a function -HANDLE_OTHER_INST(49, Select , SelectInst ) // select instruction -HANDLE_OTHER_INST(50, UserOp1, Instruction) // May be used internally in a pass -HANDLE_OTHER_INST(51, UserOp2, Instruction) // Internal to passes only -HANDLE_OTHER_INST(52, VAArg , VAArgInst ) // vaarg instruction -HANDLE_OTHER_INST(53, ExtractElement, ExtractElementInst)// extract from vector -HANDLE_OTHER_INST(54, InsertElement, InsertElementInst) // insert into vector -HANDLE_OTHER_INST(55, ShuffleVector, ShuffleVectorInst) // shuffle two vectors. -HANDLE_OTHER_INST(56, ExtractV...

----- Original Message ----- > From: "James Molloy via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Vaivaswatha Nagaraj" <vn at compilertree.com> > Cc: "LLVM Dev" <llvm-dev at lists.llvm.org> > Sent: Thursday, December 3, 2015 4:41:46 AM > Subject: Re: [llvm-dev] Function attributes for LibFunc and its impact on GlobalsAA > >

...::ID, bool, bool, llvm::SDValue, std::vector<llvm::TargetLowering::ArgListEntry, std::allocator<llvm::TargetLowering::ArgListEntry> >&, llvm::SelectionDAG&, llvm::DebugLoc) constin libLLVMSelectionDAG.a(SelectionDAGBuilder.cpp.o) llvm::SelectionDAGBuilder::visitVAArg(llvm::VAArgInst const&)in libLLVMSelectionDAG.a(SelectionDAGBuilder.cpp.o) llvm::SelectionDAGISel::LowerArguments(llvm::BasicBlock const*)in libLLVMSelectionDAG.a(SelectionDAGBuilder.cpp.o) llvm::TargetData::getTypeAllocSize(llvm::Type const*) constin libLLVMSelectionDAG.a(SelectionDAGBuilder.cpp.o...

...whether this cmpxchg is atomic between threads or only within a diff --git a/lib/Analysis/AliasAnalysis.cpp b/lib/Analysis/AliasAnalysis.cpp index 36ed40d..9583bbe 100644 --- a/lib/Analysis/AliasAnalysis.cpp +++ b/lib/Analysis/AliasAnalysis.cpp @@ -338,7 +338,7 @@ AliasAnalysis::getModRefInfo(const VAArgInst *V, const Location &Loc) { AliasAnalysis::ModRefResult AliasAnalysis::getModRefInfo(const AtomicCmpXchgInst *CX, const Location &Loc) { // Acquire/Release cmpxchg has properties that matter for arbitrary addresses. - if (CX->getOrdering() > Monotonic) + if (CX->getSuccessOrd...