[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

[Chris Lattner]

On Apr 2, 2008, at 10:10 AM, Dale Johannesen wrote:

>
> 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.

I don't think anyone with working dwarf support would ever want "- 
enable-correct-eh".  I think this is fine.

>>> 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.

Anything that shrinks EH data is goodness, but I agree it is probably  
not a high priority.

-Chris