llvm dev - Jun 2011 - [LLVMdev] Is LLVM expressive enough to represent asynchronous exceptions?

On Jun 13, 2011, at 2:52 PM, Chris Lattner wrote:
> Synchronous exceptions like divide by zero or null pointer derefs are
another thing entirely though.
When runtimes support this, do they preserve all registers or just the
non-volatile registers, like a normal unwinder? How is information about the
exception passed to the landing pad?

/jakob

On Jun 13, 2011, at 3:15 PM, Jakob Stoklund Olesen wrote:
> 
> On Jun 13, 2011, at 2:52 PM, Chris Lattner wrote:
> 
>> Synchronous exceptions like divide by zero or null pointer derefs are
another thing entirely though.
> 
> When runtimes support this, do they preserve all registers or just the
non-volatile registers, like a normal unwinder? How is information about the
exception passed to the landing pad?
> 
> /jakob
> 

Anything is possible. In my experience, all registers are preserved by the
runtime, and the compiler has to describe each trapping instruction in a lookup
table.

-Andy

On Jun 13, 2011, at 3:15 PM, Jakob Stoklund Olesen wrote:
> 
> On Jun 13, 2011, at 2:52 PM, Chris Lattner wrote:
> 
>> Synchronous exceptions like divide by zero or null pointer derefs are
another thing entirely though.
> 
> When runtimes support this, do they preserve all registers or just the
non-volatile registers, like a normal unwinder? How is information about the
exception passed to the landing pad?
The idea is that each of these potentially trapping synchronous operations needs
to be treated as a potential control flow operation, just like
"invoke" is to "call".

-Chris

On Jun 13, 2011, at 11:18 PM, Chris Lattner wrote:
> 
> On Jun 13, 2011, at 3:15 PM, Jakob Stoklund Olesen wrote:
> 
>> 
>> On Jun 13, 2011, at 2:52 PM, Chris Lattner wrote:
>> 
>>> Synchronous exceptions like divide by zero or null pointer derefs
are another thing entirely though.
>> 
>> When runtimes support this, do they preserve all registers or just the
non-volatile registers, like a normal unwinder? How is information about the
exception passed to the landing pad?
> 
> The idea is that each of these potentially trapping synchronous operations
needs to be treated as a potential control flow operation, just like
"invoke" is to "call".
I think Jakob wants to know if the register allocator needs to clobber volatile
regs at the trapping instructions. One way to model the trap is exactly like a
conditional branch to the handler. In fact, whether the code emitter generates a
trapping instruction or a conditional branch can be considered a detail of code
emission that is hidden from the register allocator. This helps make the
optimization of error checking code language and target independent--it's
really the same problem whether the language supports exceptions or the
target+runtime supports resuming from trapping instructions. Maybe that's
not obvious to folks yet because the C front end doesn't currently tell the
optimizer which conditions are exceptional--something that could be rectified.
Anyway back to the point... if traps are modeled this way, then of course the
runtime must preserve all registers.

If there are no handlers or cleanup code, the CFG looks gratuitous on visual
inspection, which I think is the objection to this representation.

-Andy