similar to: [LLVMdev] ARM and lowerinvoke

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 somewhere. SelectDAGBuild and >

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

I'm getting a very stubborn assertion failure that I don't understand. After I insert a call to an externally defined function into an invoked function, llc spits out the following assertion failure when I compile the bytecode: llc: SelectionDAGISel.cpp:4912: virtual bool llvm::SelectionDAGISel::runOnFunction(llvm::Function&): Assertion `FuncInfo.CatchInfoFound.size() ==

Here it is: llc: SelectionDAGISel.cpp:358: virtual bool llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&): Assertion `FuncInfo->CatchInfoFound.size() == FuncInfo->CatchInfoLost.size() && "Not all catch info was assigned to a landing pad!"' failed. 0 libLLVM-2.7.so 0x0140e2c8 Stack dump: 0. Program arguments: llc -O0 bullet.linked.bc.opt 1.

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

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,

Hi, My transformation phase inserts an if-the-else construct into a BB. If that BB contains llvm.eh.exception, I get an Assertion at some later point: lib/CodeGen/SelectionDAG/FunctionLoweringInfo.cpp:212: void llvm::FunctionLoweringInfo::clear(): Assertion `CatchInfoFound.size() == CatchInfoLost.size() && "Not all catch info was assigned to a landing pad!"' failed. Is

The diff is not only the && and || but also the leading !: diff --git a/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp b/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp index 58f029fbe9fc..7ee06fc153b2 100644 --- a/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp +++ b/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp @@ -659,7 +659,7 @@ void SelectionDAGISel::CodeGenAndEmitDAG() {

Hi Ankur, > The flags "-view-sched-dags".. described in the doc doesn't seem to work. ( > "llc -help" doesn't list it ). as far as I remember, displaying DAGs during compilation is only enabled in "debug builds" [1] of LLVM. You probably have to re-configure and re-compile LLVM to enable this feature. Best regards, Christoph [1]

Hi, In SelectionDAGISel::SelectAllBasicBlocks if (TM.Options.EnableFastISel) FastIS = TLI->createFastISel(*FuncInfo, LibInfo); followed by if (!FastIS) { LowerArguments(Fn); } else { The above implies that implementing FastIS is optional. In contrast to that, testing whether FastIS is actually been used is done by testing if TM.Options.EnableFastISel is set. For example

I am trying to understand the SelectionDAG construction from LLVM IR. I have gone through the doc "The LLVM Target-Independent Code Generator" on LLVM site. This gives a great initial overview. However I am unable to catch the actual control flow for the llvm->selectionDag conversion. The flags "-view-sched-dags".. described in the doc doesn't seem to work. ( "llc

Hi, It's changed a few times over the last year. I believe xdg-open spawns whichever application your desktop environment would use to open the file so you should be able to tell it to use dotty. From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Ryan Taylor via llvm-dev Sent: 11 August 2015 00:30 To: llvm-dev at lists.llvm.org Subject: [llvm-dev] Fwd: [LLVMdev]

Daniel, Ok, thanks. Simple fix. We'll just make correction in local copy for now, one less thing to port later :) Thanks. On Mon, Jul 27, 2015 at 12:29 PM, Daniel Sanders <Daniel.Sanders at imgtec.com> wrote: > I've just looked at my checkout of 3.6 and it looks like the fix wasn't > merged. I don't have the revision number for the fix to hand but in >

Hi Kostya, > My transformation phase inserts an if-the-else construct into a BB. > If that BB contains llvm.eh.exception, I get an Assertion at some later point: > > lib/CodeGen/SelectionDAG/FunctionLoweringInfo.cpp:212: > void llvm::FunctionLoweringInfo::clear(): Assertion `CatchInfoFound.size() == > CatchInfoLost.size() && "Not all catch info was assigned to a

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

I've just looked at my checkout of 3.6 and it looks like the fix wasn't merged. I don't have the revision number for the fix to hand but in lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp, this: MatchFilterBB = (!FilterDAGBasicBlockName.empty() && FilterDAGBasicBlockName == FuncInfo->MBB->getBasicBlock()->getName().str());

Hi Kenneth, this way of implementing unwind won't interact properly with dwarf exception handling. That's rather bad. Ciao, Duncan.

It seems that fast-isel for intel does not handle strlen. It's a general problem in fast-isel . ~/llvmw/build/Deb~/llvmw/build/Debug+Asserts/bin/clang -O0 -mllvm -fast-isel-verbose -mllvm -fast-isel strlen1.c strlen1.c:12:3: warning: implicitly declaring library function 'printf' with type 'int (const char *, ...)' printf("%i\n", len); ^

Hi Dale, > 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? yes, though see below. > Chris would also like to discuss renaming the EH command line   > options, and I have to agree

On Thu, 20 Dec 2007, Duncan Sands wrote: > Hi Dale, >> If these were visible to end users I would not like exposing sjlj, an   >> implementation detail; however my understanding is that they aren't.   >> On the basis that they're intended for use by llvm geeks, I think   >> either of these is an improvement, except in the second case I think   >> the