[llvm-commits] [llvm] r94726 - in /llvm/trunk: docs/ExceptionHandling.html include/llvm/CodeGen/MachineModuleInfo.h include/llvm/Intrinsics.td lib/CodeGen/AsmPrinter/DwarfException.cpp lib/CodeGen/MachineModuleInfo.cpp lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp lib/CodeGen/SjLjEHPrepare.cpp

Jim Grosbach grosbach at apple.com
Thu Jan 28 08:16:15 PST 2010


On Jan 28, 2010, at 1:26 AM, Duncan Sands wrote:

> Hi Jim,
> 
>> Update of 94055 to track the IR level call site information via an intrinsic.
>> This allows code gen and the exception table writer to cooperate to make sure
>> landing pads are associated with the correct invoke locations.
> 
> I didn't get what this is for, can you please explain.  Also, some testcases
> would be good.  Finally, it sounds like you are introducing yet another eh
> intrinsic that will get shifted around by the optimizers causing endless
> trouble - please tell me it ain't so!
> 

SJLJ needs to assign the call site numbering earlier than the DWARF assembly printer since it needs to create create a dispatch table and insert code to assign the value into the function context. After SJLJ has run, there's no guarantee the landing pads and/or invoke containing BBs won't be reordered, so there needs to be a way to make sure that when we construct the call site table in the LSDA, we associate the proper landing pad with its associated call site number.

My first pass at this didn't use an intrinsic, but rather used a side-table. The best place I found for it, however, was the Function object, which Chris correctly pointed out isn't a very good place at all. After code-gen, the information is kept in MachineModuleInfo, which is where other similar side-table information is kept. There doesn't seem to be an equivalent place before that, though. If you have a suggestion, I'm all ears! Practically speaking, I don't expect this intrinsic to get moved around. It's inserted very late, right before code-gen, and is then removed by the selection DAG build process. That said, there's no theoretical reason it couldn't be, which you're right, is a bad thing, and is why I shied away from doing it this way the first time around. At this point, though, I think it's the lesser of two evils.

-Jim



More information about the llvm-commits mailing list