Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

live-interval trouble with exception handling #1874

Closed
llvmbot opened this issue Jun 6, 2007 · 6 comments
Closed

live-interval trouble with exception handling #1874

llvmbot opened this issue Jun 6, 2007 · 6 comments
Labels
bugzilla Issues migrated from bugzilla

Comments

@llvmbot
Copy link
Member

llvmbot commented Jun 6, 2007

Bugzilla Link 1502
Resolution FIXED
Resolved on Feb 22, 2010 12:51
Version unspecified
OS Linux
Attachments Patch marking exception registers as live-in on the landing pad
Reporter LLVM Bugzilla Contributor
CC @asl

Extended Description

Logically speaking, the exception register and exception selector register
should be marked as live-in on landing pads. (Currently they are marked
live-in on the block containing the EXCEPTIONADDR/EHSELECTION selections,
which seems wrong). I wrote a patch to fix this, but then live-intervals
blows up on several testcases in the testsuite, for example:
(1) CodeGen/Generic/2007-04-14-EHSelectorCrash.ll. Here the problem seems
to be that there is no landing pad but there is a EHSELECTION instruction.
So the exception selector register is used without being marked live-in
anywhere.
(2) CodeGen/Generic/2007-06-06-CriticalEdgeLandingPad.ll. Here the registers
are not used in the landing pad itself (they are used in a sucessor).
Live-intervals doesn't seem to like having registers marked as live-in without
actually being used in that machine basic block.

Could a live-intervals expert please take a look?

@llvmbot
Copy link
Member Author

llvmbot commented Jun 18, 2007

Sorry about the lateness. I want to take a look at this now but the patch does
not apply cleanly against tot. Can you supply a new patch?

@llvmbot
Copy link
Member Author

llvmbot commented Jun 19, 2007

new patch
Hi Evan, here's a refresh patch. Enjoy!

@llvmbot
Copy link
Member Author

llvmbot commented Jun 21, 2007

Note that the test CodeGen/Generic/2007-04-14-EHSelectorCrash.ll
is now marked XFAIL because it causes the following assertion to
fire in SelectionDAGISel (the assertion shouldn't really exist -
it is part of a hack to workaround an exception handling problem
that we don't yet have a good solution for):

#ifndef NDEBUG
assert(FuncInfo.CatchInfoFound.size() == FuncInfo.CatchInfoLost.size() &&
"Not all catch info was assigned to a landing pad!");
#endif

If you remove that assertion and un-XFAIL the test, you should see
the assertion in live-intervals that I mentioned in the initial
bugreport.

@llvmbot
Copy link
Member Author

llvmbot commented Jun 27, 2007

Working on #​2. Initial thoughts: LiveIntervals::computerIntervals() should
traverse the graph in df order. If the live-in eh registers are not used, then
they should be live-outs and propagated as live-ins to the successors.

@llvmbot
Copy link
Member Author

llvmbot commented Jun 27, 2007

If the live-in eh registers are not used

I guess you mean: if the live-in eh registers are not killed.

@llvmbot
Copy link
Member Author

llvmbot commented Jun 27, 2007

Nevermind. I've decided the proper fix is to simply add the EH register(s) as a
livein in the landing pad successor (and any block in the path from the landing
pad to the said block). I've also fixed live-interval to not to puke if a livein
is not used.

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070625/050807.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070625/050808.html

Let me know if you run into other issues.

2007-04-14-EHSelectorCrash.ll is still XFAIL due to the CatchInfo issue. Please
open another bug to track that (if there isn't one already).

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 3, 2021
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bugzilla Issues migrated from bugzilla
Projects
None yet
Development

No branches or pull requests

1 participant