similar to: [LLVMdev] Optimizer to remove duplicate loads?

Hi, On 24/02/13 06:48, edA-qa mort-ora-y wrote: > Which optimizer would remove duplicate, or unneeded loads? In my > generator I end up having a lot of the same load. For example here I > keep loading "@pt" which will always be the same value. in order to do this, the optimizers need to know that the call to @trace_integer does not modify the contents of @pt. Is it logically

On 24/02/13 09:02, Duncan Sands wrote: > in order to do this, the optimizers need to know that the call to > @trace_integer does not modify the contents of @pt. Is it logically > possible for them to deduce this? If not, no optimizer can do what > you want. Yeah, I thought about that and then realized in this context they could not (it's an external function). Is there some

I'm having an issue where a certain set of types and insert/extractvalue are producing the incorrect values. It appears as though extractvalue getting my sub-structure is not getting the correct data. I have these types: %outer = type { i32, %inner, i1 } %inner = type { double, i32 } The trouble is that when I have a value of type %outer then proceed to extract the components of the

I have some exception handling which works fine using the JIT. Now I am producing object files and linking them, but the exception handling tables seem to be missing. I call _Unwind_RaiseException and get _URC_END_OF_STACK as a result. I produce my object file using TargetMachine::addPassesToEmitFile and then I link my resulting files with: gcc -o prog input.o -fexceptions I'm sure I'm

On 17/10/13 23:57, Bill Wendling wrote: > There shouldn't be any special linker flags you need to use. If > you're getting segfaults, it's probably trying to access the data at > an invalid location or something. Make sure that your EH table is > properly aligned. You might want to hand calculate the values to make > sure that they're correct. What platform are you

I saw something strange in the optimized LLVM code. It appears that sometimes an inlined function is optimized though the function itself is not optimized to the same level. Below is an example of an unoptimized/non-inlined function call: define void @_entry() uwtable { entry: %0 = call i64 @eval_expr() call void @trace_integer(i64 %0) ret void } 'eval_expr' is a big ugly series

On Oct 17, 2013, at 7:24 PM, edA-qa mort-ora-y <eda-qa at disemia.com> wrote: > On 17/10/13 23:57, Bill Wendling wrote: >> There shouldn't be any special linker flags you need to use. If >> you're getting segfaults, it's probably trying to access the data at >> an invalid location or something. Make sure that your EH table is >> properly aligned. You

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'm getting an error that I don't know how to fix. I've isolated the input as much as I easily can. I've attached the file that produces the problem. Just calling "llc err.ll -o err.s" generates the error. I'm going to try and isolate even further, but as I'm not sure what I'm looking for I don't know if I'll be successful. Does anybody know what this

That makes it more mysterious then since I am indeed only calling a main function. Perhaps I have to invoke it a different way. Here's my call I have now: auto main = linker->getModule()->getFunction( "main" ); std::vector<llvm::GenericValue> args(2); args[0].IntVal = llvm::APInt( platform::abi_int_size, 0 ); args[1].PointerVal = nullptr; llvm::GenericValue gv =

Is there a way to get the size of a type in the IR assembly code? I know the size must be known since alloca and getelementptr both implicitly use it, but I don't see any way to get access to the size directly. I know my final compiler will have to get the size itself, but I'm just doing some simple tests directly in assembly now and am hoping there is an easy way to get the size of a

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

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

Hi, On 11/04/13 06:06, edA-qa mort-ora-y wrote: > I have some exception handling which works fine using the JIT. Now I am > producing object files and linking them, but the exception handling > tables seem to be missing. I call _Unwind_RaiseException and get > _URC_END_OF_STACK as a result. you will get this if no catch clauses match (eg because there are no catch clauses, perhaps

It was the return type which was i64. I changed it also to my abi_int_size and it works now. I have to take care of a few other type translations, but it looks like MCJIT is working now. Thank you. On 08/11/13 18:12, Yaron Keren wrote: > Something must be wrong with the Function Type. Try to debug into > runFunction to see which if condition fails. > Just a guess, if this is on 64

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,

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

Something must be wrong with the Function Type. Try to debug into runFunction to see which if condition fails. Just a guess, if this is on 64 bit system the first argument type may be int64 but needs to be int32. Yaron 2013/11/8 edA-qa mort-ora-y <eda-qa at disemia.com> > That makes it more mysterious then since I am indeed only calling a main > function. Perhaps I have to invoke

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

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.