similar to: [LLVMdev] Aligning structures/members?

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

On 19/11/13 08:03, Caldarale, Charles R wrote: >> X = { a, b, c, d, e } >> Y = { c, d, e } > In general, no. If a, b, and c were char, and d was an int, using > typical C alignments, there would be one slack byte between c and d > in X, whereas there would be three in Y. You could probably force > what you want with packed structures or by playing with the data >

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'm getting frustrated by assertions whenever I create a store inst (via builder CreateStore). I get the error "Ptr must be a pointer to Val type!" My destination is a pointer to an equivalent to the source type. The problem is that the types were created via different generation paths and the underlying structure is a distinct object (with the exact same fields). I seem to recall

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

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

I've done some playing with zero-sized arrays and would like to confirm that my findings are correct. I can't easily test on a lot of platforms, nor is this clearly covered in the docs, so I'd like to be sure before I rely heavily on it. 1. A zero-sized array in a structure will be aligned to the natural alignment of the contained type. That is, [0 x T] will be aligned appropriately

Is a series of fields in a structure guaranteed to have the same layout as those fields in a structure on their own? That is, can I cast a pointer within a main structure to an equivalent type? X = { a, b, c, d, e } Y = { c, d, e } y = BitCast( StructGEP( some_x, 2 ), Y* ) Is that a valid cast? -- edA-qa mort-ora-y Leaf Creator Leaf - the language we always wanted http://leaflang.org/

I'm having a problem with my code generating empty lines and it appears to be the CLib `open` function generating an empty line when used within the JIT-VM. If I compile my program to an exe file it doesn't happen. I also have a lot of other code running in the VM without this problem, it's somehow particular to `open`. A chunk of my IR that calls `open`: defer_body_26:

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.    

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(        

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 ).

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

Super, that clarifies a lot what happens.  And yes, it's been a challenge calling C APIs with by-value structures, but I think I've got it working now, at least on x86_64 Linux. If I understood correctly, when llvm sees a struct like `foo = { i8, i64, float }` and then a function like `bar( %foo )` it is the same as the function `bar( i8, i64, float )`?  Is the call guaranteed to be byte

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

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'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

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.

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

My code to create an ExecutionEngine is segfaulting: std::string errStr; llvm::ExecutionEngine * ee = llvm::EngineBuilder( unique_ptr<llvm::Module>(module) ) .setErrorStr( &errStr ) //line 1618 .setEngineKind( llvm::EngineKind::JIT ) Where module is a `llvm::Module*`. This is code I'm migrating from 3.3 to 3.8. Since the deletion error is happening during