[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

[Duncan Sands]

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.

remind me again why the SJLJ logic isn't part of the code that builds
the SDag?

Thanks,

Duncan.