similar to: Slow IR compilation/JIT, profiling points to LLVM?

Displaying 20 results from an estimated 800 matches similar to: "Slow IR compilation/JIT, profiling points to LLVM?"

2018 May 05
0
Slow IR compilation/JIT, profiling points to LLVM?
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
2018 May 05
0
Slow IR compilation/JIT, profiling points to LLVM?
Hi, On 2018-05-05 08:04:54 +0200, edA-qa mort-ora-y via llvm-dev wrote: > 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
2018 May 05
2
Slow IR compilation/JIT, profiling points to LLVM?
On 05/05/18 17:58, Andres Freund wrote: > You're building LLVM with assertions enabled > (-DLLVM_ENABLE_ASSERTIONS=ON). > Some of those are fairly expensive... > Is there another way to get LLVM to check the correctness of my IR without the assertions? That's what I'm assuming I need the flag for (it's been a long time since I experimented with it) If there is no way
2018 Apr 18
4
A struct {i8,i64} has size == 12, clang says size 16
I'm creating a struct of `{i8,i64}` and `DataLayout::getTypeAllocSize` is returning `12`. `getStructLayout` also gives an `4` offset for the second element. The native ABI, and clang, for the same type are producing a size of 16, with an alignment of 8, for the second element. This is for the system triple "x86_64-linux-gnu" What could be causing this difference in alignment and
2018 Apr 18
0
A struct {i8, i64} has size == 12, clang says size 16
It sounds like your DataLayout may not match clang's for x86_64-linux. What does it say about the alignment of i64? On Wed, Apr 18, 2018 at 12:05 PM edA-qa mort-ora-y via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I'm creating a struct of `{i8,i64}` and `DataLayout::getTypeAllocSize` > is returning `12`. `getStructLayout` also gives an `4` offset for the > second
2018 Apr 18
2
A struct {i8, i64} has size == 12, clang says size 16
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
2018 May 05
0
Slow IR compilation/JIT, profiling points to LLVM?
Hi, On 2018-05-06 00:19:42 +0200, edA-qa mort-ora-y wrote: > On 05/05/18 17:58, Andres Freund wrote: > > You're building LLVM with assertions enabled > > (-DLLVM_ENABLE_ASSERTIONS=ON). > > Some of those are fairly expensive... > > > > Is there another way to get LLVM to check the correctness of my IR > without the assertions? That's what I'm
2018 Apr 19
0
A struct {i8, i64} has size == 12, clang says size 16
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
2018 Mar 17
1
Migration from 3.8 to 6.0 questions (segfault most concerning)
I'm encountering a few problems in my migration that I haven't yet figured out. `getOrInsertFunction` is generating a SEGFAULT at FunctionType::isValidArgumentType(llvm::Type*).  I'm calling it as:     generic_ptr_ = llvm::PointerType::get( llvm::Type::getInt8Ty(context), 0 );     f_natural_int = llvm::IntegerType::get(context, 64);     module->getOrInsertFunction(        
2018 Apr 19
2
How to set Target/Triple of ExecutionEngine
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.    
2018 Apr 19
1
How to set Target/Triple of ExecutionEngine
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 ).
2018 Apr 18
3
Why does clang do a memcpy? Is the cast not enough? (ABI function args)
Yes, but why is it even copying the memory?  It already has a pointer which it can cast and load from -- and does so in other scenarios. I'm wondering whether this copying is somehow required and I'm missing something, or it's just an artifact of the clang emitter. That is, could it not omit the memcpy and cast the original variable? On 18/04/18 19:43, Krzysztof Parzyszek via
2018 Apr 19
0
How to set Target/Triple of ExecutionEngine
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
2018 Apr 19
0
Why does clang do a memcpy? Is the cast not enough? (ABI function args)
I believe the memcpy is there just as a consequence of Clang's design - different parts of the compiler own different pieces of this, so in some sense one hand doesn't see what the other is doing. Part of it is "create an argument" (memcpying the local variable into an unnamed value) and then the next part is "oh, but that argument gets passed in registers, so decompose it
2018 Apr 18
2
Why does clang do a memcpy? Is the cast not enough? (ABI function args)
I'm implementing function arguments and tested this code in C:     // clang -emit-llvm ll_struct_arg.c -S -o /dev/tty     typedef struct vpt_data {         char a;         int b;         float c;     } vpt_data;         void vpt_test( vpt_data vd ) {     }     int main() {         vpt_data v;         vpt_test(v);     } This emits an odd LLVM structure that casts to the desired struct type,
2018 Apr 22
2
Difference between "byval" and actually passing by value?
There appears to be a difference between passing by value:     call void @foo(%some_struct %v) And using the `byval` attribute on a pointer:     call void @foo(%some_struct* byval %v) They are not compatible with each other yet logically do the same thing.  The second form is the one that appears to work with the ABI on linux, and the first one not. What is the reason for the difference? --
2018 Apr 18
2
Why does clang do a memcpy? Is the cast not enough? (ABI function args)
I understand it's passing by value, that's what I'm testing here. The question is why does it copy the data rather than just casting and loading values from the original variable (%v) ?  It seems like the copying is unnecessary. Not all struct's result in the copy, only certain forms -- others are just cast directly as I was expecting. I'm just not clear on what the
2018 Apr 18
0
Why does clang do a memcpy? Is the cast not enough? (ABI function args)
On 18 Apr 2018, at 18:40, edA-qa mort-ora-y via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I'm implementing function arguments and tested this code in C: > > // clang -emit-llvm ll_struct_arg.c -S -o /dev/tty > typedef struct vpt_data { > char a; > int b; > float c; > } vpt_data; > > void vpt_test( vpt_data
2018 Apr 18
2
Why does clang do a memcpy? Is the cast not enough? (ABI function args)
Yes, I understand that as well (it's what I'm trying to recreate in my language now). I'm really wondering why it does the copy, since from what I can tell it could just as easily cast the original value and do the load without the memcpy operation. That is, the question is about the memcpy and extra alloca -- I understand what it's doing, just not why it's doing it this way.
2018 Apr 18
0
Why does clang do a memcpy? Is the cast not enough? (ABI function args)
It is a matter of the calling convention. It would specify what structs are passed in registers, and which are passed through stack. -Krzysztof On 4/18/2018 12:28 PM, edA-qa mort-ora-y via llvm-dev wrote: > I understand it's passing by value, that's what I'm testing here. The > question is why does it copy the data rather than just casting and > loading values from the