[llvm-commits] [llvm-gcc-4.2] r49253 - /llvm-gcc-4.2/trunk/gcc/llvm-backend.cpp

[Duncan Sands]

Hi,

> Where I am coming from here is that -fexceptions and -funwind-tables  
> are mutually exclusive,

the Ada f-e sets both.  Or rather, it sets -fexceptions and
-fnon-call-exceptions, and toplevel.c sets -funwind-tables
because of -fnon-call-exceptions.  So they don't look very
mutually exclusive to me...  Also, in opts.c the flag is
initialized as
  flag_unwind_tables = targetm.unwind_tables_default;
which also implies that it is not mutually exclusive with
-fexceptions.

> which is true for the environments we care   
> about (although as usual the documentation is mightily confusing).  - 
> funwind-tables will thus mark all calls nounwind, and all definitions  
> not-nounwind; I do think the current nounwind bit is adequate to do    
> this.  Pruning EH would not find any landing pads, and should not  
> remove the unwinding info ("frame moves"), so we shouldn't run it.
> 
> If my belief is not true in some other circumstances, e.g. Ada, that  
> would not work.  This is the right behavior for Darwin x86-64, at  
> least I think so; I could certainly make it contigent on that if it's  
> breaking Ada.

My impression is that -funwind-tables means: always output frame moves
and other dwarf stuff, even if it appears not to be needed.  If so, then
how about:
(1) a new flag for llc (-keep-unwind-tables)
(2) if the flag is set, output eh info even if the function is marked
nounwind.

Ciao,

Duncan.