similar to: [LLVMdev] can an alias Value be created?

Hi, I''m building a frontend for a legacy schema, with tables like this: CREATE TABLE `types` ( `a_type_cd` varchar(6) NOT NULL default '''', `a_type` varchar(30) NOT NULL default '''', PRIMARY KEY (`a_type_cd`) ); The primary key is specified by the user (not auto-generated), and needs to be updateable. I create the following a base class to

Hi all, I wrote code that compiled with llvm 2.8, but now I'm using llvm 2.9 and it doesn't compile anymore: My code looks like this: User *U; ... if (PHINode * phi = dyn_cast<PHINode>(U)) { ... BasicBlock * Pred = phi->getIncomingBlock(I); ... } And when I compile it with clang: Live.cc:130:27: error: member access into

It was the return type which was i64. I changed it also to my abi_int_size and it works now. I have to take care of a few other type translations, but it looks like MCJIT is working now. Thank you. On 08/11/13 18:12, Yaron Keren wrote: > Something must be wrong with the Function Type. Try to debug into > runFunction to see which if condition fails. > Just a guess, if this is on 64

I can confirm that both are compiled properly: A) PHINode *PN; for (BasicBlock::iterator I = H->begin(); PN = dyn_cast<PHINode>(I); I++) .... B) for (BasicBlock::iterator I = H->begin; isa<PHINode>(I); I++) { PHINode *PN = cast<PHINode(I); .... } I'll make a patch for whatever solution do you prefer (this problem is a showstopper for more than a dozen

Hi all, Here the first bunch of patch for compiling part of LLVM under win32 with MSVC 7.1: * Trivial addings (I hope!): - #include <string> at top of: llvm\include\llvm\ExecutionEngine\ExecutionEngine.h(78) : error C2039: 'string' : is not a member of '_STL' - #include <algorithm> at top of: llvm\lib\CodeGen\LiveIntervalAnalysis.cpp(639) : error C2039:

On Fri, 3 Sep 2004, Paolo Invernizzi wrote: > I can confirm that both are compiled properly: Ok. > for (BasicBlock::iterator I = H->begin; isa<PHINode>(I); I++) { > PHINode *PN = cast<PHINode(I); > .... > } > > I'll make a patch for whatever solution do you prefer (this problem is > a showstopper for more than a dozen files...) I prefer this

That makes it more mysterious then since I am indeed only calling a main function. Perhaps I have to invoke it a different way. Here's my call I have now: auto main = linker->getModule()->getFunction( "main" ); std::vector<llvm::GenericValue> args(2); args[0].IntVal = llvm::APInt( platform::abi_int_size, 0 ); args[1].PointerVal = nullptr; llvm::GenericValue gv =

Something must be wrong with the Function Type. Try to debug into runFunction to see which if condition fails. Just a guess, if this is on 64 bit system the first argument type may be int64 but needs to be int32. Yaron 2013/11/8 edA-qa mort-ora-y <eda-qa at disemia.com> > That makes it more mysterious then since I am indeed only calling a main > function. Perhaps I have to invoke

Hi Paolo, > <snip> > for (BasicBlock::iterator I = Dest->begin(); PHINode *PN = > dyn_cast<PHINode>(I); ++I) > visitPHINode(*PN); > <snip> > > build_vc71\lib\Transforms\Scalar\SCCP.cpp(202) : error C2275: > 'llvm::PHINode' : illegal use of this type as an expression > > but I think is a NO-NO, so suggestions? Since it's fussy

I guess I didn't have a clear question. Suppose we have BB1 and BB2 both point to BB3. BB1 has variable x. BB2 also as variable x. BB3 will have PHINode for x with 2 value from BB1 and BB2. BB1 BB2 \ / BB3 Now if BB1 and BB2 is extracted into a function (using ExtractCodeRegion), they will be replaced by a basic block called codeRepl (which has a call to the extracted

Here's what I've got so far - it seems to work, aside from the fact that DeleteDeadPHIs is not removing at least one dead PHI in my test program. --------------------- static bool mergeBlockIntoSuccessor(BasicBlock *pred, BasicBlock *succ) { if (succ == pred) return false; if (pred->getFirstNonPHI() != pred->getTerminator()) return false; //

Hi folks, Hope this is not a silly question. But it bothers me when I am thinking about it. My question is: 1. In the implementation of serverSplitPHINodes(), why it only checks the first PHI node for possible multiple inputs from outside the region to extract. There could be more than one PHI nodes in the header block, and the code only checks the first one. I don't quite get it.

This is a pretty nice warning. Should we enable it for LLVM's build when the host compiler supports it? Benjamin Kramer via llvm-commits <llvm-commits at lists.llvm.org> writes: > Author: d0k > Date: Mon Feb 22 07:11:58 2016 > New Revision: 261524 > > URL: http://llvm.org/viewvc/llvm-project?rev=261524&view=rev > Log: > Fix some abuse of auto flagged by

On Thu, 28 Jul 2005, Naftali Schwartz wrote: > I now understand that IndVarSimplify.cpp is capable of reproducing array > references when the pointer initialization from the array address is found > inside the immediately enclosing loop, such that in the following code: Ok. > int A[20000], B[100], Z; > int main() > { > int i, j, *a, *b; > for ( a =

Hi! I'm trying to run Blender using Mesa OpenCL implementation on a radeonsi card. First the kernel didn't want to compile, but that was caused by a bug in it (they were using . instead of -> in 1 place), and after fixing this bug I've got the kernel to compile... ...But after that, LLVM started to crash during translation of IR into shader code with R600 backend.

Hi all, I was trying to implement an obfuscation tool for C-code on the basis of LLVM. I got a prototype of the simple obfuscation transformation which converting control flow graph to something like a state machine. I am not sure I will have time to work on extending further this tool with new transformations like opaque predicates and decided to put here source code I have by now with hope

The enlosed patch for IndVarSimplify.cpp works even when the pointer increment is deeply nested wrt pointer initialization, but note that it needs to have loop structures preserved, as in the following: int A[3000000], B[20000], C[100], Z; volatile int I, J, K; int main() { int i, j, k, *a, *b, *c; for ( a = &A[0], i = 0; i != 300; i++ ) { I++;

Does this help? http://nondot.org/sabre/LLVMNotes/SizeOf-OffsetOf-VariableSizedStructs.txt On 11 Nov 2012, at 10:52, edA-qa mort-ora-y <eda-qa at disemia.com<mailto:eda-qa at disemia.com>> wrote: Is there a way to get the size of a type in the IR assembly code? I know the size must be known since alloca and getelementptr both implicitly use it, but I don't see any way to get

This is just a quick note the let everyone know dyn_cast now works properly with BasicBlock::iterator's and others. In other words, you can now do things like this: for (BasicBlock::iterator I = BB.begin(); PHINode *PN = dyn_cast<PHINode>(I); ++I) ... instead of this: for (BasicBlock::iterator I = BB.begin(); PHINode *PN = dyn_cast<PHINode>(&*I); ++I) ...

Is there a way to get the size of a type in the IR assembly code? I know the size must be known since alloca and getelementptr both implicitly use it, but I don't see any way to get access to the size directly. I know my final compiler will have to get the size itself, but I'm just doing some simple tests directly in assembly now and am hoping there is an easy way to get the size of a