similar to: [LLVMdev] JIT pass runtime struct on to subroutines

Hi everyone, I have some problems with gettings the X86_thiscall calling convention to work. I am new to LLVM, so if this is the wrong place for this question then I appologise, please tell me where to go instead. I am generating code to call a member function of a class compiled with Microsoft Visual C++ using the JIT compiler. The following code is used to register the pointer to the

I'm trying to generate the declarations for function intrinsics, and I must be misunderstanding how to create new functions - I saw that a function with no basic blocks is treated as a declaration, so I tried to just create one and add it to the globals list: llvm_type *structTy, *ptrToStructTy; structTy = llvm_type_create_struct(0, 0); structTy =

On May 16, Chris Lattner wrote: > > Sure, that sounds good. I'd definitely prefer that it be tested before it > goes into CVS. Perhaps adding something to llvm/examples would be a good > way to go. > > One suggestion, you might change the API to be something like this: > > ParseAsmString(const char *, Module *) > > Where the function parses the string and

Hello, I would like to have your opinions on this. *Problem:* Currently, there are no ways to perform hypercalls into LLVM (they transfer execution from the program being executed to the LLVM infrastructure to perform compilation). The goal of this project is to cleanly integrate an API into the LLVM code/execution engine to create custom callbacks. The “lli” executable should allow having a

Hello everyone, i’m using LLVM (updated to 3.1 after seeing that bug, but it’s the same with 3.0) for running a bitcode on a C++ program, and Clang for compiling it. My code work perfectly, as expected on x64, but crash on x86. I’m on Windows 7 x64 and LLVM + Clang was compiled using Visual Studio 2010 (tested in both Release and Debug build). Project was make using CMake. Here is my code:

Hi edaqa, You might need to set your TargetOptions before calling selectTarget. E.g. builder.setTargetOptions(Opts).selectTarget(...); Or you could just let EngineBuilder call selectTarget for you (which is what the no-argument version of EngineBuilder::create does): llvm::ExecutionEngine * ee = builder. setErrorStr( &errStr ). setEngineKind( llvm::EngineKind::JIT ).

Hello, I am trying to isolate an assertion failure in if-converter (on PPC) and I generated a textual debuglog with: ``` LLVM_ARGS=-print-before-all -print-module-scope -filter-print-funcs=japi1__require_7687 ``` and after splicing out the the MIR before the if-converter pass I would like to run `llc -march=ppc64le -run-pass=if-converter input.mir` so that I can start minimising the MIR. This

Taking one step back, I'm not clear I'm even setting the triple/DataLayout on the module correctly:     module = new llvm::Module( "test", *llvm_context );     module->setTargetTriple( platform::target->triple ); Is that enough to create an appropriate DataLayout for the module?  I don't see anyway to convert a triple to a DataLayout, so I can't call

I don't know if I'm setting the triple of my execution engine correctly.  This is leading to an issue where a struct `{i8,i64}` is not getting the same layout as the ABI expects. I setup my engine/module like this:      llvm::SmallVector<std::string,2> mattrs;      llvm::EngineBuilder builder{ unique_ptr<llvm::Module>(module) };      llvm::ExecutionEngine * ee = builder.    

Hi, Could you share how you compile IR and which version of JIT you use (Orc, MCJIT)? Could it be that you are using interpreter instead of actual JIT? Cheers, Alex. > On 5. May 2018, at 08:04, edA-qa mort-ora-y via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I'm having issues of my compiler, and JIT execution, of LLVM IR being > rather slow. It's accounting for

Valentin, in terms of limitations as Sean pointed out, an important one is that .mir doesn't have MachineFunctionInfo which may result in failure on accesses to global variables due to use of register X2. The verifier considers it an undefined register. Also, it's probably easier to reduce test cases using bugpoint starting from an IR test case. With the code you provided, I get a

Hello Valentin, To generate a mir test case i think the process is to first create an IR file by passing '-S -emit-llvm' to clang, then you can feed that file into llc and use stop-before to get the mir just before the if-converter pass, eg: `llc -stop-before=if-converter -simplify-mir -o test.mir test.ll`. Also there is a MIR language reference: https://llvm.org/docs/MIRLangRef.html

I'm having issues of my compiler, and JIT execution, of LLVM IR being rather slow. It's accounting for the vast majority of my full compilation time.  I'm trying to figure out why this is happening, since it's becoming an impediment.  (Note: by slow I mean about 3s of time for only about 2K of my front-end code, 65K lines of LLVM-IR) Using valgrind I see some functions which seem

I'm not sure if this helps, but here it is in case it does. I typically use bugpoint in a way as to keep the actual failure that I'm after. For example, with the test case you've pasted, I was looking for a specific assert. So I used bugpoint this way: $ cat reduceme.sh #!/bin/bash llc -filetype=obj $1 2>&1 | grep 'Cannot lower calls with arbitrary operand bundles'

Thank you both! I was running into the issue that bugpoint was reducing my test-case into other failures and I hadn't managed yet to find the right point in the Julia pass pipeline to insert the module to reproduce the issue reliably from llc and that's why I started looking at using the MIR. I will go back at looking at the pass pipeline and the IR and get a reproducer that way!

On Thu, Oct 31, 2013 at 11:39 PM, sumeeth kc <sumeethkc at gmail.com> wrote: > Hello, > > I would like to have your opinions on this. > > *Problem:* > > Currently, there are no ways to perform hypercalls into LLVM (they > transfer execution from the program being executed to the LLVM > infrastructure to perform compilation). The goal of this project is to >

In our fork of LLVM we often need to reduce a crash testcase for a specific assertion. After writing lots of "only give me this specific assertion" scripts like the above I decided to write a script that automates all this for me: <https://github.com/CTSRD-CHERI/clang/blob/master/utils/creduce_crash_testcase.py>. (It's called creduce_crash_test.py but it will actually use

What exactly is your alignment settings in your LLVM struct? Something like this would tell you the alignment of "something". const llvm::DataLayout dl(theModule); size_t size = dl.getPrefTypeAlignment(something); IIn "my" compiler, I don't do anything special to align structs, so it's plausibly your specific data-layout that says that i64 only needs aligning to

I think I see a potential issue. My ExecutionEngine setup may not be using the same target as my object code emitting, and in this test case I'm running in the ExecutionEngine.  I'll go over this code to ensure I'm creating the same triple and see if that helps -- I'm assuming it will, since I can't imagine the exact same triple with clang would produce a different layout. On

Hi Sumeeth, I'm not sure I understand what your new mechanism is supposed to add. You can already call functions defined in the host program from generated code. The Kaleidoscope tutorial does this. If the function you want to call is defined in a module that is dynamically loaded and you are using the default memory manager all you need to do is declare a prototype for the function in