similar to: [LLVMdev] Problem with executing recompileAndRelinkFunction successively

Thanks for the tip! I looked into it and it looks like the problem as of SVN HEAD is that the lui and ori instructions in Mips are considered cheap (1-cycle def-use latency) by MachineLICM::IsCheapInstruction(), but are not trivially materializable because their register operands are not always available. This makes MachineLICM::IsProfitableToHoist() return false, preventing the hoist even

Yes machine-licm can and should hoist constant materialization instructions out of the loop. If it's not doing that, it's probably because the target is not modeling the instruction correctly. I would walk through MachineLICM::IsLoopInvariantInst() in the debugger to figure it out. You can also try compiling the same bitcode for a target like ARM or X86 as a comparison. Evan On Mar 7,

Please add a test to http://llvm.org/viewvc/llvm-project/llvm/trunk/unittests/ExecutionEngine/JIT/JITTest.cpp?view=markup verifying that recompileAndRelinkFunction() keeps working. Then this fix will look fine to me. On Tue, Dec 22, 2009 at 12:23 AM, Gianluca Guida <glguida at gmail.com> wrote: > On Tue, Dec 22, 2009 at 6:14 AM, Chris Lattner <clattner at apple.com> wrote: >>

Hello, JIT::recompileAndRelinkFunction's runJITOnFunction does not use the MCI arg, causing null pointer deferences at every call. Attached patch makes runJITOnFunction more reliable. Thanks, Gianluca -- It was a type of people I did not know, I found them very strange and they did not inspire confidence at all. Later I learned that I had been introduced to electronic engineers.

Hi Varun, I see the point of your question, but I'm not the best person to answer from that perspective. Nadav Rotem is the owner of the x86 backend, and he can probably give you a more complete answer than I could. Thanks, Andy From: Varun Agrawal [mailto:vagrawal at cs.stonybrook.edu] Sent: Friday, October 11, 2013 8:48 PM To: Kaylor, Andrew; llvmdev at cs.uiuc.edu Subject: RE: Building

On Tue, Dec 22, 2009 at 6:14 AM, Chris Lattner <clattner at apple.com> wrote: > On Dec 19, 2009, at 3:36 PM, Gianluca Guida wrote: >> Attached patch makes runJITOnFunction more reliable. > > When would MCI be null? Everytime you call recompileAndRelinkFunction. It calls runJITOnFunction without specifying the MCI argument, which get defaulted to NULL. Gianluca -- It was a

On Tue, Dec 22, 2009 at 5:51 PM, Jeffrey Yasskin <jyasskin at google.com> wrote: > Please add a test to > http://llvm.org/viewvc/llvm-project/llvm/trunk/unittests/ExecutionEngine/JIT/JITTest.cpp?view=markup > verifying that recompileAndRelinkFunction() keeps working. Then this > fix will look fine to me. Here it is. Unfortunately I'm not exactly a C++ guy so I'm open to

Dear All, "recompileAndRelinkFunction" found in Interpreter and previously in JIT, is not found in MCJIT. Can I just implement it in MCJIT like its old definition in JIT, or it contradicts with some design issue in MCJIT? Regards, Marwa Yusuf Teaching Assistant - Computer Engineering Department Faculty of Engineering - Benha University E-JUST PhD Student Computer Science &

Hi Andrew, I think I diluted my question. My question was not related to MCJIT. I ran the following 4 scenarios: (1)gcc -mcpu=corei7 tetris.c -o tetris (2)gcc -mcpu=athlon64 tetris.c -o tetris (3)clang -march=corei7 tetris.c -o tetris (4)clang -march=athlon64 tetris.c -o tetris In (1) and (2), I see difference in order of instructions in the output binaries, which I expected because every CPU

Hi Varun, Have you tried your experiment with icc by any chance? The MCJIT component does not assume that you will be executing the generated code on the host system because it can be used to generate code for external targets. However, you can specify the CPU by calling setCPU() on the EngineBuilder object before creating your execution engine. (You can use sys::getHostCPUName() to figure out

On Dec 19, 2009, at 3:36 PM, Gianluca Guida wrote: > Hello, > > JIT::recompileAndRelinkFunction's runJITOnFunction does not use the > MCI arg, causing null pointer deferences at every call. > > Attached patch makes runJITOnFunction more reliable. When would MCI be null? -Chris

Hi, I am using the LLVM JIT infrastructure (MCJIT). I wanted to see if there are any performance gains as the compiler can detect the target CPU at runtime. But, I didn't see any improvement (I compile with -no-mmx and -no-sse). I then tried an experiment, where I compiled the program with clang-3.3, with and without specifying the target cpu as "corei7". I was shocked to see that

my changed code. namespace { class MyLoopPass:public LoopPass { bool changed; public: static char ID; Loop* curLoop; // AnalysisType* AA; DominatorTree* DT; LoopInfo* LI; MyLoopPass() : LoopPass(ID){} bool isLoopInvariantInst(Instruction &I) ; bool runOnLoop(Loop * L, LPPassManager &lpm); virtual void getAnalysisUsage(AnalysisUsage &AU) const {

Hi, I am experimenting with creating instructions that write into virtual registers that use the ARM GPRPair register class in Pre-RA phase. During register allocation, I hit an assertion because the code is not in SSA form: lib/CodeGen/MachineRegisterInfo.cpp:271: llvm::MachineInstr* llvm::MachineRegisterInfo::getVRegDef(unsigned int) const: Assertion `(I.atEnd() || llvm::next(I) ==

That's a good point.  But it's worth noting that recompileAndRelinkFunction() and freeMachineCodeForFunction() are both vestiges of the old JIT (i.e. the "JIT" as opposed to the "MCJIT").  The old JIT is no longer actively supported. -Phil On April 26, 2014 at 9:47:05 AM, Sri (emdcdeveloper at gmail.com) wrote: Hi Fillip                  Addition to my previous

Hello. Does anybody have an idea why I'm getting the error below when using llc with arguments -O1 -disable-cgp? Note that this error is not given when using llc -O0. (I'd like to mention also I'm using custom Instruction selection for BUILD_VECTOR, which gets converted in my back end's machine instrution VLOAD_D, although the custom code seems to always select

Hi, I'm still having problems implementing my custom inserter in the X86 backend. I found a solution to my last problem (http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-October/078296.html), by using a virtual register. The binary works when it's compiled in -O0, but not in -O1,-O2,... I really can't figure what I'm doing wrong... Any idea? Here is the code of my custom

Hi All, I work on a backend for a target similar to Mips, where large immediates are loaded into registers with 2 instructions, 1 to load the MSBits and 1 to load the LSBits. I've noticed a recurring pattern where, despite low register pressure, these constants will be rematerialized in every iteration of a loop, rather than being hoisted. Here's an example using the

What are the correct target description side effect flags for instructions which may trap (e.g. divide / remainder)? The divide instruction in my backend currently has no flags set. I've enabled the MachineLICM pass and it's causing a miscompilation by hoisting a divide by zero instruction out of the loop. Clearly this pass needs to be made aware that this is not safe. The current

Jay Foad wrote: >> I'm linking a program (my ellsif driver) that basically brings in most >> of the LLVM stuff: bitcode reading, optimizations, linking, and target >> code generation. >> >> All of a sudden, I'm getting the following when I run: >> [~/elsa/ellsif] dev% ./ellsif -v test/ofmt.i test/sieve.i -time-actions >> -O5 >>