similar to: [LLVMdev] Warnings on Opt passes

On 09/11/13 23:27, Renato Golin wrote: > My main concern is not correctness, that should have been taken care by > the front-end and the sanitizers, but things like we already do with the > debug messages, only less verbose, and possibly formatted in a special > way, so that other front-end tools can read and propose changes to the code. How many such messages would be generated? If

It seems like a difficult thing to do since we would have to keep metadata intact across transformations, which, AFAIK, is not done. mem2reg, for example, doesn't even propagate debug metadata to phi nodes, and I'm not really sure if it's valid to do so. Also, line information alone seems to be insufficient for providing accurate warnings. Debug metadata does contain variable names,

On 9 November 2013 15:03, Henrique Santos <henrique.nazare.santos at gmail.com>wrote: > It seems like a difficult thing to do since we would have to keep metadata > intact across transformations, which, AFAIK, is not done. > mem2reg, for example, doesn't even propagate debug metadata to phi nodes, > and I'm not really sure if it's valid to do so. > I understand

There was a pretty lengthy discussion on this a few months ago - http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-July/063845.html I think people were mostly for the idea, but I don't know how far, if at all, they implemented these ideas. If the diagnostic/warning capabilities are good enough, I think it'll be an interesting thing to have. Also, Paul Redmond implemented something of the

On 03/11/13 12:16, Henrique Santos wrote: > You could try placing a phi node at "defer_block" with incoming value > "result" > when the incoming block is "entry", and do the same for "null" and > "landing". > Then, instead of loading "result", you load the value given by the newly > created phi. That seems like the

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

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

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

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

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.

I'm trying to get MCJIT working but I get the following errors: Full-featured argument passing not supported yet! UNREACHABLE executed at MCJIT.cpp:322! I'm sure the first one will be a problem, but the second one prevents me from testing anything. I don't know how to fix the problem. My code works when using the non-MC JIT, and I added to my EngineBuilder: .setUseMCJIT(true)

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 working on exception handling and having some trouble with type information. My personality/types work fine when running in the JIT, but when I produce object files and link them it fails. In particular, from an action record and the LSDA I get a type table entry. The problem is this doesn't appear to be pointing to a valid location. If I derefence it a segfault occurs. Are there

Does this help? http://nondot.org/sabre/LLVMNotes/SizeOf-OffsetOf-VariableSizedStructs.txt On 11 Nov 2012, at 10:52, edA-qa mort-ora-y <eda-qa at disemia.com<mailto:eda-qa at disemia.com>> wrote: 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

I'm having trouble figuring out what the error "Instruction does not dominate all uses!" means. I'm trying to construct a call to a function with two parameters. The printed IR, with error, looks like this: define i32 @add(i32, i32) { EntryBlock: %2 = add i32 %0, %1 ret i32 %2 } define i32 @eval_expr() { EntryBlock: ret i32 <badref> } Instruction does not dominate

In my language I have anonymous types (essentially tuples), and I have generated functions (like constructors) which are unique for these types. If the same type occurs in multiple modules however it should end up with only one definition being linked. Thus I need a way to give them the same name. The problem is that if I derive the name from what the type contains the length of that name is