[llvm-commits] [llvm] r49064 - in /llvm/trunk: include/llvm/CodeGen/MachineModuleInfo.h lib/CodeGen/DwarfWriter.cpp lib/CodeGen/LLVMTargetMachine.cpp lib/CodeGen/MachineModuleInfo.cpp lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp lib/Target/PowerPC/PPCAsmPrinter.cpp lib/Target/PowerPC/PPCRegisterInfo.cpp lib/Target/X86/X86ATTAsmPrinter.cpp lib/Target/X86/X86AsmPrinter.cpp lib/Target/X86/X86RegisterInfo.cpp

Dale Johannesen dalej at apple.com
Wed Apr 2 10:10:08 PDT 2008


On Apr 2, 2008, at 5:17 AM, Duncan Sands wrote:

> Hi Dale,
>
>> Recommitting EH patch; this should answer most of the
>> review feedback.
>
> yes, this is much better - thanks a lot!
>
>> -enable-eh is still accepted but doesn't do anything.
>
> What is the status of -enable-correct-eh?

It will not cause non-Dwarf to be emitted for targets that support  
Dwarf.
I guess that's a change;  can put it back the way it was if you think  
it's
important.  It don't think it ever worked on Darwin anyway, so this  
isn't
something I'm interested in.

>> The separation of the EH table and frame move data is,
>> I think, logically figured out, but either one still
>> causes full EH info to be generated (not sure how to
>> split the metadata correctly).
>
> Me neither, but it would be a nice win if we could.  Want
> to open a PR for this?

I'm not sure it's even possible on Darwin; our linker has a fair  
amount of
knowledge about EH tables built into it, and may not take kindly to  
having them change.
There is also the matter of binary compatibility with gcc-compiled code.

>>   void BeginFunction(MachineFunction *MF) {
>>     this->MF = MF;
>> -
>> -    if (MMI &&
>> -        ExceptionHandling &&
>> -        TAI->doesSupportExceptionHandling()) {
>> -      shouldEmit = true;
>> -      // Assumes in correct section after the entry point.
>> -      EmitLabel("eh_func_begin", ++SubprogramCount);
>> +    shouldEmitTable = shouldEmitMoves = false;
>> +    if (TAI->doesSupportExceptionHandling()) {
>> +
>> +      // Map all labels and get rid of any dead landing pads.
>> +      MMI->TidyLandingPads();
>
> There used to be a check that MMI is not NULL, but not anymore.

Replaced (though I don't think MMI can be null there).

>> +  bool needsFrameInfo = (MMI && MMI->hasDebugInfo()) ||
>
> How about calling this needsFrameMoves?  I don't feel strongly
> about this.

Why not.  Done.




More information about the llvm-commits mailing list