similar to: Floor-integer-div and integer sign operations?

Hacker's Delight or this web page are probably the best references for tricks like this: https://graphics.stanford.edu/~seander/bithacks.html#CopyIntegerSign John On 03/30/2018 03:58 AM, edA-qa mort-ora-y via llvm-dev wrote: > I'm looking for ways to do some basic operations without using branches. > > The key operation I want is a floored/round-to-negative-infinity integer

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

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(        

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

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

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

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,

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

Does an array of a value type and a structure containing only that type have the same alignment requirements?  That is, in C-syntax: float* array; struct point { float x; float y; } point p; array = (float*)&p; Does `array[0]` now refer to x, and `array[1]` to y? I'm creating these structures in LLVM with default packing (StructType::isPacked == false). I have a library that takes

Is there some way to create a target-specific C-ABI compatible function signature using LLVM? For example, this C-Code:     typedef struct vpt_data {         char x;         int a;         char c;         float b;     } vpt_data;         void vpt_test( vpt_data vd ) { Generates a function:     define void @vpt_test(i64 %vd.coerce0, i64 %vd.coerce1) #0 { And also packs/unpacks the structure

I'm unable to figure out how IR attributes can be added via the C++ API. I need to create a function like this:     %1 = call i64 @abi_call_test_tuple_2p(%struct.abi_tuple_2p* byval align 8 %v) Where a structure is being passed by value. I need to add the `byval` attribute somewhere (I'm not clear if this is on the function arguments or the type). I'm also uncertain of why that

I'm unintentionally allocating too much space on the stack by using `alloca` inside a loop. To fix this I will do my `alloca` outside of the loop itself.  I'm wondering if there is a way for this to be automatically done: given alloca a function scope, rather than loop scope. I'm curious also, since this actually allocates each time in the loop, is there a way to say the stack

On 06/05/18 00:21, Andres Freund wrote: > That's what I do (using Orc to JIT parts of SQL queries). By default I > have the debug build of postgres linked against debug LLVM w/ > assertions, and the optimized build against an optimized LLVM wo/ > assertions (albeit with symbols). I've tried a builld with assertions off and it has only a relatively minor impact (a 10% drop in

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

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

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

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