search for: lowerinvoke

On 6 March 2014 18:09, Mark Seaborn <mseaborn at chromium.org> wrote: > LowerAtomic "lowers atomic intrinsics to non-atomic form for use in a > known non-preemptible environment". LowerInvoke strips out exception > handling by converting invokes to calls, so that landingpads, resumes, etc. > become dead and can be removed by a later pass. > > (As an aside, LowerInvoke has an option for using SJLJ exception handling, > but that option appears to be unused and replaced >...

All, I'm looking at the lowerinvoke pass as a starting point for getting SJLJ based exception handling working on ARM, but am having some troubles with it. When I run a simple testcase (attached) through llc and specify -enable-correct-eh-support, llc asserts on me. It appears there's been some bitrot somewhere. SelectDAG...

Hi Jim, > I'm looking at the lowerinvoke pass as a starting point for getting > SJLJ based exception handling working on ARM, but am having some > troubles with it. When I run a simple testcase (attached) through llc > and specify -enable-correct-eh-support, llc asserts on me. It appears > there's been some bitrot...

...bit systems. If the C compiler >> takes issue with this, it would be best to tell the CBE to emit casts to C >> (long) or something. > > Actually that's the only case I stumbled over this problem in a somewhat > larger C++ program, and it's clearly the wrong type in LowerInvoke.cpp - it > really should be IntPtrTy. But maybe we could use just IntTy here to avoid > target dependencies. Note that this is perfectly legal llvm code and the CBE should work on it. The reason this doesn't show up often is because the instcombine pass shrinks longs to ints on 32-bi...

On Apr 21, 2009, at 1:53 PM, Jim Grosbach wrote: > All, > > I'm looking at the lowerinvoke pass as a starting point for getting > SJLJ based exception handling working on ARM, but am having some > troubles with it. When I run a simple testcase (attached) through > llc and specify -enable-correct-eh-support, llc asserts on me. It > appears there's been some bitrot...

On Fri, 13 May 2005, Markus F.X.J. Oberhumer wrote: > There is still one unneeded LongTy in LowerInvoke.cpp - something like this > pseudo-diff should probably get applied. What does this impact? -Chris > Index: LowerInvoke.cpp > =================================================================== > RCS file: /var/cvs/llvm/llvm/lib/Transforms/Scalar/LowerInvoke.cpp,v > retrieving re...

On Fri, 13 May 2005, Markus F.X.J. Oberhumer wrote: > Chris Lattner wrote: >> On Fri, 13 May 2005, Markus F.X.J. Oberhumer wrote: >> >>> There is still one unneeded LongTy in LowerInvoke.cpp - something like >>> this pseudo-diff should probably get applied. >> >> >> What does this impact? > > This causes code like > > write(2, (&(l227_abortmsg[0ll])), 95); > > in the CBE, which not all 32-bit compilers do like. Ah ok, in that cas...

Although most of the leaks I detected in LLVM were from singleton objects, there also seem to be some real leaks. One such leak (which is creating problems for me when I try to get rid of the constant singletons) seems to be a GlobalVariable created on line 145 of Transforms/Scalar/lowerInvoke.cpp -- any suggestions how I can make sure this GlobalVariable gets deleted? Actually I'm a bit confused in general with how LLVM manages memory and I could not find anything in the documentation section -- from what I have seen in the source code it seems like bigger structures (Modules,...

The functions that I placed in ScalarTargetTransformInfo are functions what were used by LSR and LowerInvoke. getJumpSize and getJumpAlignment are used by LowerInvoke. Do you suggest that I remove them from TargetLowering and keep them in ScalarTargetTransformInfo ? Thanks, Nadav On Oct 9, 2012, at 5:47 PM, Evan Cheng <evan.cheng at apple.com> wrote: > Hi Nadav, > > The concept and th...

...wind and invoke to setjmp/ > longjmp (slow) or turn invokes into calls and unwinds into abort()s. > Ah cheers, Alastair. That could be very useful (at least for me personally, I don't mind the slow so much as long as it behaves correctly!) I did a bit of research. Looks like it's -lowerinvoke, not -lowerunwind. http://llvm.org/docs/Passes.html#lowerinvoke That provides the two options you describe. Now this question is perhaps getting a bit off-topic, but I can't find a tool which accepts the -lower* arguments. Is there a tool for running such passes? Or can it only be accessed f...

Hello, Jim > -enable-correct-eh-support, llc asserts on me. It appears there's been some > bitrot somewhere. Well, correct. Because many places expects exceptions to be dwarf-style. > Is it reasonable to expect that lowerinvoke is a good place to start for > doing what I'm after? I really don't think so. Since you're trying to map dwarf-based structures into sjlj couch. I think you need to start looking how gcc / llvm-gcc implements them, do proper lowering inside llvm-gcc and then "fix" DAG machi...

On Fri, 2005-05-13 at 08:06 +0200, Markus F.X.J. Oberhumer wrote: > Actually that's the only case I stumbled over this problem in a somewhat > larger C++ program, and it's clearly the wrong type in LowerInvoke.cpp - > it really should be IntPtrTy. But maybe we could use just IntTy here to > avoid target dependencies. Wait a minute. You want to lower a 64 bit thing to a 32 bit and "avoid target dependencies" when the right type is a pointer? You know the 64-bit targets won't like...

im compiling llvm with visual studio 10. I have used cmake build app. visual studio 10 is complaining about error c2039: 'setjmp' : is not a member of llvm::Intrinsic its line 154, LowerInvoke.cpp any ideas? -- View this message in context: http://old.nabble.com/errors-when-compiling-with-visual-studio-10-tp29427176p29427176.html Sent from the LLVM - Dev mailing list archive at Nabble.com.

...s an improvement, except in the second case I think   > the default should be target-dependent.  Comments? How about having -enable-eh turn on dwarf eh on all targets (including those that don't support it, in which case intrinsics get lowered to nothing much IIRC), and also have it cause a LowerInvoke pass to be run on targets that do not support dwarf eh. Since LowerInvoke can result in costly code, add a -disable-eh-emulation option (more or less equivalent to the opposite of -enable-correct-eh-support) which causes the LowerInvoke pass not to do anything (like !-enable-correct-eh-support doe...

Chris would like to turn on -enable-eh rather than -enable-correct-eh- support in the llvm testsuite for those targets that support it. The following patch is intended to turn it on for x86 and ppc. Anton, Duncan, are you OK with this? -------------- next part -------------- A non-text attachment was scrubbed... Name: mf.patch Type: application/octet-stream Size: 669 bytes Desc: not

...h to choose whether codegen should turn > unwind/invoke into dwarf or setjmp/longjmp style code. There is, but it happens before codegen and is slow. -enable-correct-eh-support will translate invoke/unwind into setjmp/longjmp pairs for the correct behavior. See: http://llvm.org/docs/Passes.html#lowerinvoke Nick > > Ciao, > > Duncan. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > -- Nick Johnson

...do i want to reload them? is this normal. what should I do? gafferuk wrote: > > im compiling llvm with visual studio 10. I have used cmake build app. > > visual studio 10 is complaining about error c2039: 'setjmp' : is not a > member of llvm::Intrinsic > its line 154, LowerInvoke.cpp > > any ideas? > -- View this message in context: http://old.nabble.com/errors-when-compiling-with-visual-studio-10-tp29427176p29428525.html Sent from the LLVM - Dev mailing list archive at Nabble.com.

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

From what I understand, the unwind instruction is implemented only for the interpreter: there is a -lowerunwind pass for compiling to other systems which will either lower unwind and invoke to setjmp/ longjmp (slow) or turn invokes into calls and unwinds into abort()s. On 26 Dec 2008, at 15:19, Matt Giuca wrote: > > > Jon Harrop wrote: >> >> Is it? I was just reading

...my patch for it: Index: ReleaseNotes.html =================================================================== --- ReleaseNotes.html (revision 166627) +++ ReleaseNotes.html (working copy) @@ -669,6 +669,9 @@ "TargetTransformInfo" provides a number of low-level interfaces. LSR and LowerInvoke already use the new interface. </p> +<p> The TargetData structure has been renamed to DataLayout and moved to VMCore + to remove the dependency on Target </p> + <ul> <li>...</li> </ul> I'll add information on the multi-pointer additions once it...