On 23 February 2015 at 01:29, Kamal Sharma <kgs1.rice at gmail.com> wrote:> Hi Dibyendu, > > It would be very helpful if you could post the original source code or > snippet. > That way, one can investigate deeper to understand the problem. > > Regards, > Kamal Sharma >Hi Kamal, Sure. I guess I ought to create a test that one can look in isolation. I am working on building a JIT compiler for Lua (actually a derivative of Lua). It is currently work in progress. The approach is to compile Lua bytecodes into LLVM IR. The IR generated from my code is here (after optimization I should add): https://github.com/dibyendumajumdar/ravi/blob/master/clang-output/lua_op_loadk_return_ravi.ll I am using the output from Clang as a guide to generating IR. So I write small snippets of code in C which are equivalent to Lua bytecodes - then use Clang to emit the IR. I use this to work out the IR I need to build. The C equivalent of the program I am compiling is here: https://github.com/dibyendumajumdar/ravi/blob/master/clang-output/lua_op_loadk_return.c The difference between the C version and what I generate is that I put a load of the "base" pointer at the beginning of every Lua opcode. This is because some Lua opcodes can reallocate the memory pointed to by base. I was hoping that the optimizer will get rid of the redundant stuff. The code generation is all done here: https://github.com/dibyendumajumdar/ravi/blob/master/src/ravijit.cpp I don't expect you to wade through all this - but I will be grateful for any help / guidance you can provide. Thanks and Regards Dibyendu
You have not installed the DataLayout in the Module, as I had pointed out earlier. Compile a small program using clang, to get IR. You will notice a "target datalayout" declaration at the top of the IR. There is no such declaration in your IR. This is precisely the problem I had. You need to add the DataLayout to the Module, at which point a "target datalayout" declaration will appear in your IR, and the optimization passes will have enough alias information to be able to eliminate your redundant loads. On Mon, Feb 23, 2015 at 2:02 AM, Dibyendu Majumdar <mobile at majumdar.org.uk> wrote:> On 23 February 2015 at 01:29, Kamal Sharma <kgs1.rice at gmail.com> wrote: > > Hi Dibyendu, > > > > It would be very helpful if you could post the original source code or > > snippet. > > That way, one can investigate deeper to understand the problem. > > > > Regards, > > Kamal Sharma > > > > Hi Kamal, > > Sure. I guess I ought to create a test that one can look in isolation. > > I am working on building a JIT compiler for Lua (actually a derivative > of Lua). It is currently work in progress. > The approach is to compile Lua bytecodes into LLVM IR. > > The IR generated from my code is here (after optimization I should add): > > https://github.com/dibyendumajumdar/ravi/blob/master/clang-output/lua_op_loadk_return_ravi.ll > > I am using the output from Clang as a guide to generating IR. So I > write small snippets of code in C which are equivalent to Lua > bytecodes - then use Clang to emit the IR. I use this to work out the > IR I need to build. > > The C equivalent of the program I am compiling is here: > > https://github.com/dibyendumajumdar/ravi/blob/master/clang-output/lua_op_loadk_return.c > > The difference between the C version and what I generate is that I put > a load of the "base" pointer at the beginning of every Lua opcode. > This is because some Lua opcodes can reallocate the memory pointed to > by base. I was hoping that the optimizer will get rid of the redundant > stuff. > > The code generation is all done here: > > https://github.com/dibyendumajumdar/ravi/blob/master/src/ravijit.cpp > > I don't expect you to wade through all this - but I will be grateful > for any help / guidance you can provide. > > Thanks and Regards > Dibyendu > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150223/d3d26c32/attachment.html>
On 23 February 2015 at 11:22, David Jones <djones at xtreme-eda.com> wrote:> You have not installed the DataLayout in the Module, as I had pointed out > earlier. >Hi David, I reported earlier that I tried this but there was no improvement. Well I ran another test to be sure. The results are below. As you can see the loads are still present. ; ModuleID = 'ravi_module_ravif1' target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128" target triple = "x86_64-pc-windows-msvc-elf" %0 = type { %ravi.TValue*, i32*, i64 } .... %6 = load %ravi.TValue** %base %srcvalue = getelementptr inbounds %ravi.TValue* %5, i32 0, i32 0, i32 0 %destvalue = getelementptr inbounds %ravi.TValue* %6, i32 0, i32 0, i32 0 %7 = load double* %srcvalue store double %7, double* %destvalue %srctype = getelementptr inbounds %ravi.TValue* %5, i32 0, i32 1 %desttype = getelementptr inbounds %ravi.TValue* %6, i32 0, i32 1 %8 = load i32* %srctype store i32 %8, i32* %desttype %9 = load %ravi.TValue** %base %10 = getelementptr inbounds %ravi.TValue* %9, i32 1 %11 = getelementptr inbounds %ravi.TValue* %5, i32 1 %srcvalue1 = getelementptr inbounds %ravi.TValue* %11, i32 0, i32 0, i32 0 %destvalue2 = getelementptr inbounds %ravi.TValue* %10, i32 0, i32 0, i32 0 %12 = load double* %srcvalue1 store double %12, double* %destvalue2 %srctype3 = getelementptr inbounds %ravi.TValue* %11, i32 0, i32 1 %desttype4 = getelementptr inbounds %ravi.TValue* %10, i32 0, i32 1 %13 = load i32* %srctype3 store i32 %13, i32* %desttype4 %14 = load %ravi.TValue** %base %15 = getelementptr inbounds %ravi.TValue* %14, i32 2 %16 = getelementptr inbounds %ravi.TValue* %5, i32 2 %srcvalue5 = getelementptr inbounds %ravi.TValue* %16, i32 0, i32 0, i32 0 %destvalue6 = getelementptr inbounds %ravi.TValue* %15, i32 0, i32 0, i32 0 %17 = load double* %srcvalue5 store double %17, double* %destvalue6 %srctype7 = getelementptr inbounds %ravi.TValue* %16, i32 0, i32 1 %desttype8 = getelementptr inbounds %ravi.TValue* %15, i32 0, i32 1 %18 = load i32* %srctype7 store i32 %18, i32* %desttype8 %19 = load %ravi.TValue** %base
Hi, I added tbaa metadata and that seems to have improved things - now the redundant loads are getting removed. I did not find any documentation on how to use the API, but eventually figured out by looking at what Clang produces, and how the Julia project is using this. I will write this up in the next few days but if anyone wants to see how I am doing it then here is the link to the commit: https://github.com/dibyendumajumdar/ravi/commit/87f3720f7eb661385be1199e48f4107d04a66671 Regards Dibyendu