Chris,
it is goodness that the LandingpadInst will be pinned to
the beginning
of a BasicBlock,... except for the possibility of PHINode
instructions that _must_
come even earlier.?.
I can't exactly put my finger on what's going to go wrong with this,
but it sure smells fishy...
my current understanding is that the LandingpadInst will "define"
some hard
registers which will be used by following code to switch to the
corresponding
catch-clause
the lifetimes of these hard registers ostensibly starts at the
LandingpadInst,
but for purposes of PHI lowering and Register Allocation they _must_
actually
start at the beginning of the BasicBlock -- since that is where
control flow will
return to from the _Unwind_RaiseException / __gcc_personality_v0 calls,
and it is the _Unwind_ and _personality_ functions that physically
set those
hard registers, not the "LandingpadInst".
Somehow PHI lowering and register allocation need to be prohibited from
using those hard registers for spill code at the beginning of a
"landing pad block",
but I don't see how that will "fall out" of the current design.?.
-Peter Lawrence.
On Aug 3, 2011, at 12:35 AM, llvmdev-request at cs.uiuc.edu wrote:
>
> I agree with Bill in this case. The reason for landingpad to be an
> instruction is a) make it clear that it is magic in several ways
> (e.g. pinned to the start of a block), and b) so that
> LandingPadInst can have a bunch of useful accessors on it.
>
> -Chris
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20110804/b496683a/attachment.html>
Hi Peter, Thanks for pointing this out. Some us who are concerned with codegen have discussed the problem. Although the details aren't decided, you can be sure that at the MachineInstr level we won't have a landindpadInst to model liveness of exception values. Any physical registers set by the personality function will be considered live immediately after the call on the unwind path. -Andy On Aug 4, 2011, at 4:04 PM, Peter Lawrence wrote:> Chris, > it is goodness that the LandingpadInst will be pinned to the beginning > of a BasicBlock,... except for the possibility of PHINode instructions that _must_ > come even earlier.?. > > I can't exactly put my finger on what's going to go wrong with this, > but it sure smells fishy... > > > my current understanding is that the LandingpadInst will "define" some hard > registers which will be used by following code to switch to the corresponding > catch-clause > > the lifetimes of these hard registers ostensibly starts at the LandingpadInst, > but for purposes of PHI lowering and Register Allocation they _must_ actually > start at the beginning of the BasicBlock -- since that is where control flow will > return to from the _Unwind_RaiseException / __gcc_personality_v0 calls, > and it is the _Unwind_ and _personality_ functions that physically set those > hard registers, not the "LandingpadInst". > > Somehow PHI lowering and register allocation need to be prohibited from > using those hard registers for spill code at the beginning of a "landing pad block", > but I don't see how that will "fall out" of the current design.?. > > > > -Peter Lawrence. > > > > > On Aug 3, 2011, at 12:35 AM, llvmdev-request at cs.uiuc.edu wrote: > >> >> I agree with Bill in this case. The reason for landingpad to be an instruction is a) make it clear that it is magic in several ways (e.g. pinned to the start of a block), and b) so that LandingPadInst can have a bunch of useful accessors on it. >> >> -Chris >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110804/25a9e337/attachment.html>
Andrew,
yes, my brain-bad, soon after I hit the Send button
I realized it
is the InvokeInst that starts the lifetime of those hard-registers, not
the LandingpadInst, but you beat me to the reply.
-Peter Lawrence.
On Aug 4, 2011, at 4:16 PM, Andrew Trick wrote:
> Hi Peter,
>
> Thanks for pointing this out. Some us who are concerned with
> codegen have discussed the problem. Although the details aren't
> decided, you can be sure that at the MachineInstr level we won't
> have a landindpadInst to model liveness of exception values. Any
> physical registers set by the personality function will be
> considered live immediately after the call on the unwind path.
>
> -Andy
>
> On Aug 4, 2011, at 4:04 PM, Peter Lawrence wrote:
>
>> Chris,
>> it is goodness that the LandingpadInst will be pinned
>> to the beginning
>> of a BasicBlock,... except for the possibility of PHINode
>> instructions that _must_
>> come even earlier.?.
>>
>> I can't exactly put my finger on what's going to go wrong with
this,
>> but it sure smells fishy...
>>
>>
>> my current understanding is that the LandingpadInst will
"define"
>> some hard
>> registers which will be used by following code to switch to the
>> corresponding
>> catch-clause
>>
>> the lifetimes of these hard registers ostensibly starts at the
>> LandingpadInst,
>> but for purposes of PHI lowering and Register Allocation they
>> _must_ actually
>> start at the beginning of the BasicBlock -- since that is where
>> control flow will
>> return to from the _Unwind_RaiseException / __gcc_personality_v0
>> calls,
>> and it is the _Unwind_ and _personality_ functions that physically
>> set those
>> hard registers, not the "LandingpadInst".
>>
>> Somehow PHI lowering and register allocation need to be prohibited
>> from
>> using those hard registers for spill code at the beginning of a
>> "landing pad block",
>> but I don't see how that will "fall out" of the current
design.?.
>>
>>
>>
>> -Peter Lawrence.
>>
>>
>>
>>
>> On Aug 3, 2011, at 12:35 AM, llvmdev-request at cs.uiuc.edu wrote:
>>
>>>
>>> I agree with Bill in this case. The reason for landingpad to be
>>> an instruction is a) make it clear that it is magic in several
>>> ways (e.g. pinned to the start of a block), and b) so that
>>> LandingPadInst can have a bunch of useful accessors on it.
>>>
>>> -Chris
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20110804/277ca8cf/attachment.html>
On Aug 4, 2011, at 4:16 PM, Andrew Trick wrote:> Hi Peter, > > Thanks for pointing this out. Some us who are concerned with codegen have discussed the problem. Although the details aren't decided, you can be sure that at the MachineInstr level we won't have a landindpadInst to model liveness of exception values. Any physical registers set by the personality function will be considered live immediately after the call on the unwind path.Right. My intention here is to mark the CALL instruction as a terminator: BB1: %R0 = COPY %vreg0; 1st arg %R1 = COPY %vreg1; 2nd arg CALL foo Successors: BB2, BB3 BB2: Live-in: %R0 %vreg2 = COPY %R0; Return value BR BB7 BB3: LANDING PAD Live-in: %R0, %R1 %vreg10 = COPY %R0; Ex addr %vreg11 = COPY %R1; EH selector BB2 must be a layout successor of BB1, but we can already handle that. This code layout also clearly marks the call that may unwind: It is the terminator with an edge to a landing pad. That means we can get rid of the EH_LABELS we currently use to mark the call. /jakob
Guys,
on second thought...
doesn't making the exception registers live from the InvokeInst to
the LandingpadInst
create problems for critical-edge-splitting ?
if a landingpad-edge is critical and needs to be split, won't we be
creating and inserting
a new BB between the "invoke-block" and the
"landingpad-block", and
if we do then
isn't there the possibility of the register allocator spilling the
contents of the exception
registers from within the newly created block --- but this block
won't ever get executed
because the _Unwind_ / _personality_ functions will cause control
flow to go directly
to the block with the LandingpadInst ? If you really want to split
a landingpad-edge
won't you have to move the LandingpadInst up into the new block ?
if this is true (and I seem to be making a lot of logic errors
lately, so maybe reread and
proof-read the above a few times...!...) then don't we need to add
another invariant to
Bill's list:
*) there can be no code between an InvokeInst and its LandingpadInst
other than
possibly PHINodes at the beginning of the landingpad-block.
It seems that if you really do need to split a landingpad-edge then
you have to move
the LandingpadInst up into (the beginning of) the new block.
However it seems that if a landingpad-block has multiple predecessors
(often the case,
multiple InvokeInst in the main body of a try-statement all go to the
same landingpad-
block), then you cannot move the LandingpadInst in order to break a
critical edge unless
you do it for _all_ landingpad-block predecessor edges
simultaneously, but that seems
to be a messy conclusion (being forced to split other edges that
don't need to be split).
my first guess is that all the nuances of whether it ever makes sense
and/or is even
logically possible to split a critical landingpad-edge won't be
discovered except by
painful trial-and-error, and that it might be best to at first
disallow it until proven doable
by someone working in an isolated branch -- although proving it
works may be difficult,
since so little code actually uses exceptions (only TableGen in llvm ?).
-Peter Lawrence.
On Aug 4, 2011, at 4:16 PM, Andrew Trick wrote:
> Hi Peter,
>
> Thanks for pointing this out. Some us who are concerned with
> codegen have discussed the problem. Although the details aren't
> decided, you can be sure that at the MachineInstr level we won't
> have a landindpadInst to model liveness of exception values. Any
> physical registers set by the personality function will be
> considered live immediately after the call on the unwind path.
>
> -Andy
>
> On Aug 4, 2011, at 4:04 PM, Peter Lawrence wrote:
>
>> Chris,
>> it is goodness that the LandingpadInst will be pinned
>> to the beginning
>> of a BasicBlock,... except for the possibility of PHINode
>> instructions that _must_
>> come even earlier.?.
>>
>> I can't exactly put my finger on what's going to go wrong with
this,
>> but it sure smells fishy...
>>
>>
>> my current understanding is that the LandingpadInst will
"define"
>> some hard
>> registers which will be used by following code to switch to the
>> corresponding
>> catch-clause
>>
>> the lifetimes of these hard registers ostensibly starts at the
>> LandingpadInst,
>> but for purposes of PHI lowering and Register Allocation they
>> _must_ actually
>> start at the beginning of the BasicBlock -- since that is where
>> control flow will
>> return to from the _Unwind_RaiseException / __gcc_personality_v0
>> calls,
>> and it is the _Unwind_ and _personality_ functions that physically
>> set those
>> hard registers, not the "LandingpadInst".
>>
>> Somehow PHI lowering and register allocation need to be prohibited
>> from
>> using those hard registers for spill code at the beginning of a
>> "landing pad block",
>> but I don't see how that will "fall out" of the current
design.?.
>>
>>
>>
>> -Peter Lawrence.
>>
>>
>>
>>
>> On Aug 3, 2011, at 12:35 AM, llvmdev-request at cs.uiuc.edu wrote:
>>
>>>
>>> I agree with Bill in this case. The reason for landingpad to be
>>> an instruction is a) make it clear that it is magic in several
>>> ways (e.g. pinned to the start of a block), and b) so that
>>> LandingPadInst can have a bunch of useful accessors on it.
>>>
>>> -Chris
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20110805/05541c99/attachment.html>