search for: nurudeen

Hi, How can I dynamically change the code generation optimization level (e.g., None) of a JIT in other to recompile a function with a new optimization level (e.g., Default)? Thank you. Best regards, Nurudeen.

...ds = %bb1 ret i64 %1 cont: ; preds = %bb1 %3 = add i64 %0, 1 %res = call i64 @cppnative(i64 %0) br label %bb1 } C++: long cppNative(long data) { return data*data; } I am using g++ 4.5.2. I will appreciate any help. Thank you. Best regards, Nurudeen.

...llvm::DIFactory DICreator(*theModule); llvm::DICompileUnit diCompUnit = DICreator.CreateCompileUnit (DW_LANG_XXX, filename, dir, llvm::StringRef(producer), true); diCompUnit.dump(); // segmentation fault Is anything wrong with my code? Thank you, Best regards, Nurudeen. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20101025/f48f89d4/attachment.html>

> How can I dynamically change the code generation optimization level (e.g., > None) of a JIT in other to recompile a function with a new optimization > level (e.g., Default)? From the source code I'm reading, you might have to creat another JIT with different opt level. Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia

Hi Chenwj, Thank you for your response. The problem with this approach is that global mappings have to be recreated in the new JIT. Can this be somehow avoided? Best regards, Nurudeen. On Thu, March 22, 2012 10:15 pm, 陳韋任 wrote: >> How can I dynamically change the code generation optimization level >> (e.g., >> None) of a JIT in other to recompile a function with a new optimization >> level (e.g., Default)? > > From the source code I'm re...

Neat approach, I think. So you set PassManagers's Opt level rather then ExecutionEngine's one? Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj

> From: 陳韋任 [mailto:chenwj at iis.sinica.edu.tw] > Subject: Re: [LLVMdev] Execution Engine: CodeGenOpt level > So you set PassManagers's Opt level rather then ExecutionEngine's one? That's correct. I have no idea what difference doing one or the other (or both) makes. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus

...%f3 %f1a = getelementptr %sTy* %sVal, i32 0, i32 0 %f1v = load i32* %f1a %f2a = getelementptr %sTy* %sVal, i32 0, i32 1 %f2v = load double* %f2a call void @print(i32 %f1v, double %f2v, double 0x41CD6F34588147AE) ret void } I will appreciate any help on this. Thank you. Best regards, Nurudeen.

nlamee at cs.mcgill.ca writes: > I would like to understand why calling a native function from a function > in LLVM IR can be much faster than calling an equivalent function in LLVM > IR. Do you optimize the LLVM IR? The IR version can inline the call and just that would make it faster than the "native" version. Please describe how do you compile your LLVM IR. Once knowing

...xplicitly optimize the IR. I compile and run the two versions with ... GenericValue gv = EE->runFunction(bsqr, args); ... GenericValue gv2 = EE->runFunction(cppnat, args); I am calling method runFunction of ExecutionEngine. I am using the default code gen optimization level. Best regards, Nurudeen. On Thu, March 28, 2013 7:05 am, Óscar Fuentes wrote: > nlamee at cs.mcgill.ca writes: > >> I would like to understand why calling a native function from a >> function in LLVM IR can be much faster than calling an equivalent >> function in LLVM IR. >> > > Do yo...

...stract form after register allocation? 2. I would like to prevent the generation of the DBG_VALUE instruction but still be able to obtain the value (e.g., %EDI above) by saving the register code/name? 3. I would like to generate a label and take its address. Thank for your help. Best regards, Nurudeen. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20101109/09f6b4c6/attachment.html>