similar to: Should personality functions actually be functions

It seems a little backwards to me to check the landingpad's type as the first check, since the personality dictates the landingpad's type. That said, yes I see how #4 is expedient in allowing personalities using the two main types to lump themselves into EHPersonality::Unknown. As for supporting selector and exception pointer extraction for landingpad of token type, I think you'll

I have a fairly recent LLD/LTO llvm crashing on DIE *ContextDIE = getOrCreateContextDIE(Context) being null for a (local) variable. (Context is a DICompileUnit in this case, but it's not present in MDNodeToDieMap so it returns null. callstack is: llc.exe!llvm::DwarfUnit::getOrCreateTypeDIE(const llvm::MDNode * TyNode) Line 718 C++ llvm::DwarfUnit::addType(llvm::DIE & Entity, const

> I dont have a concrete design right now and I am happy to take any other ideas Three ideas come to mind, none of which are perfect: 1) I'm tempted to say that now that we have token type, landingpad should generally produce a token, the pointer should be extracted with the @llvm.eh.exceptionpointer intrinsic instead of an extractvalue, and the selector should likewise be extracted with

Hello Carlo, I tried your reproducer and faced different problem from one you described (I'm using MacOS Sierra and lld built from trunk on Mar, 15). The crash happens when SelectionDAGBuilder::lowerInvokable tries to access EH info of this function: ms_t26_RemObjects_d_Elements_d_EUnit_d_Runnerb_RunChildrennt2a_RemObjects_d_Elements_d_EUnit_d_RunContext This happens because LLVM

Hi Scott, Sorry for the late reply, I was out of office during the holidays. 1. A def node can reach either a use node, or another def node. In the highlighted phi node (p3224), the def (d3225) reaches another def (1598) in statement (s1597), that’s why it’s needed. 2. The reason why the def of R11 in s1578 is not connected directly to the use in s1725 is that there may be an intervening

Op 16-3-2018 om 20:16 schreef Evgeny Leviant: > Hello Carlo, > > I tried your reproducer and faced different problem from one you described > (I'm using MacOS Sierra and lld built from trunk on Mar, 15). The crash happens > when SelectionDAGBuilder::lowerInvokable tries to access EH info of this function: > >

> On Dec 1, 2015, at 11:14 PM, David Majnemer <david.majnemer at gmail.com> wrote: > > While we support 'opaque' types nested within struct types, they are not exactly battle tested: > > $ cat t.ll > %opaque_ty = type opaque > > %struct_ty = type { i32, %opaque_ty } > > define %struct_ty @f(%struct_ty* %p) { > %load = load %struct_ty,

Hi Philip, The error happens when the program finishes and it automatically calls the destructors, so it is not an error specifically inside my program. Here's the full code: #include "llvm/ExecutionEngine/ExecutionEngine.h" #include "llvm/ExecutionEngine/MCJIT.h" #include "llvm/IRReader/IRReader.h" #include "llvm/Support/TargetSelect.h" #include

On 08/19/2015 09:35 AM, Pete Cooper via llvm-dev wrote: > Hey Lang >> On Aug 18, 2015, at 6:04 PM, Lang Hames via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Hi All, >> >> I'd like to float two changes to the llvm.memcpy / llvm.memmove intrinsics. >> >> >> (1) Add an i1 <mayPerfectlyAlias> argument to the llvm.memcpy

Pete - That patch sounds great! Philip, Hal, Medhi, Gerolf - Thanks very much for the feedback. So how about this: (1) We drop llvm.memcpy's alignment argument and use Pete's alignment-via-metadata patch (whatever version of it passes review). (2) llvm.memcpy retains its current semantics, but we teach clang, SimplifyLibCalls, etc. to add noalias metadata where we know it's safe.

Hi Philip, Thanks for the reference, I was able to follow it and copy the code that I saw necessary, but I still have some issues (references are still not updated). I created the function: void populateVMap(llvm::ValueToValueMapTy &VMap, llvm::Function *fOld, llvm::Function *fNew) { llvm::Function::arg_iterator DestI = fOld->arg_begin(); for (llvm::Function::const_arg_iterator J =

> On Aug 19, 2015, at 12:01 PM, Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > ----- Original Message ----- >> From: "Philip Reames via llvm-dev" <llvm-dev at lists.llvm.org> >> To: "Pete Cooper" <peter_cooper at apple.com>, "Lang Hames" <lhames at gmail.com> >> Cc: "LLVM Developers Mailing

Hi All, I'd like to float two changes to the llvm.memcpy / llvm.memmove intrinsics. (1) Add an i1 <mayPerfectlyAlias> argument to the llvm.memcpy intrinsic. When set to '1' (the auto-upgrade default), this argument would indicate that the source and destination arguments may perfectly alias (otherwise they must not alias at all - memcpy prohibits partial overlap). While the C

Hi, in a recent review [0], Florian Hahn helped me to realize something that was rather surprising to me: The widely popular and very useful function llvm::Value::stripPointerCasts() can return a value with a different bit pattern than the input. Now, I think this should not be the case but I want the hear other opinions. Before I go on, please not that there is at least one location in

> On Dec 14, 2018, at 2:44 PM, Finkel, Hal J. <hfinkel at anl.gov> wrote: > > Do you have an opinion on which should be the default? > > -Hal > > Not particularly. The current name sounds to me like it would strip any casts it possibly can. Maybe most uses should now be converted to a newly named stripTrivialPointerCasts? -Matt -------------- next part

> On Dec 14, 2018, at 2:21 PM, Finkel, Hal J. via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > On 12/11/18 6:51 PM, Doerfert, Johannes Rudolf via llvm-dev wrote: >> Hi, >> >> in a recent review [0], Florian Hahn helped me to realize something that >> was rather surprising to me: >> >> The widely popular and very useful function

Hi all, We're at the point in our port of OpenVMS to x86-64 that we're working on the unwind code.  The current ABI and the current codebase doesn't have enough support for true asynchronous unwinding from any point (most notably in the prologue/epilogue) in the code that OpenVMS needs.  We're working on a set of changes to the compact unwind information to handle the additional

Hi Hal, > If you attach noalias metadata to the memcpy call, it will apply to both the source and destination; we don't have a way to differentiate. It might be true that if you attach both noalias and alias.scope metadata to the call, then querying the call against itself will return NoModRef, but that's really hacky (and, in part, wrong, because the destination still alias with

On 5/16/11 9:35 AM, Chuck Zhao wrote: > I have the following prototype for a function: > void bkp_memory(char *, int); > > Inside my LLVM IR, I have a callsite looks like the following: > tail call void @bkp_memory(i8* bitcast (i32** @P to i8*), i32 4) nounwind > > > When I try to obtain its 1st argument and check whether it is a valid > instruction, using: >

I have the following prototype for a function: void bkp_memory(char *, int); Inside my LLVM IR, I have a callsite looks like the following: tail call void @bkp_memory(i8* bitcast (i32** @P to i8*), i32 4) nounwind When I try to obtain its 1st argument and check whether it is a valid instruction, using: Instruction *Inst = dyn_cast<Instruction *>(I->getOperand(0)); it gives me a