[llvm-commits] [llvm-gcc-4.2] r93387 - /llvm-gcc-4.2/trunk/gcc/omp-low.c

[Stuart Hastings]

On Jan 14, 2010, at 1:55 AM, Duncan Sands wrote:

> Hi Stuart,
>
>> Decorate an OMP-specific MODIFY with correct lexical block.
>
> why?  Where are you going with these patches?

I'm supposed to teach llvm-gcc how to emit lexical blocks into DWARF.   
I've been testing with the GCC DejaGNU test suite, and my lexical- 
block emitter has uncovered many latent bugs, all on the GCC side.

The lexical-block emitter itself is not likely to break anything.   
However, I was obliged to change the order of declaration of local  
variables.  Currently, llvm-gcc declares all local variables at the  
entry to a function; in the new, lexical-block world, I cannot emit a  
declaration until we arrive at its lexical block (having emitted much  
unrelated code in the interim).  Of course, I must declare the locals  
in the same order whether debug info is on or off.  If the tree->LLVM  
converter discovers an un-emitted decl, it asserts, so it's now  
imperative to get the scoping correct.  I suppose I could compensate  
for missing lexical block decorations with an extra tree walk, but  
this seems like a heavy compile-time penalty.

The patches thus far are fixes for mostly harmless, latent bugs.  The  
next patch is not harmless; it fixes a latent bug in the x86-64 ABI,  
specifically in the code that assigns structures to parameter  
registers.  This code has proven very fragile, and difficult to get  
right.  If it goes in without breaking anything, the lexical-block  
emitter is next, and then I'm done.

I don't know much about your Dragon's Egg (did I spell that  
correctly?) project, but I wonder if the lexical block emitter might  
pose a problem for it.  GCC hasn't been perfectly disciplined about  
lexical blocks, compensating with searching techniques in the tree/RTL  
interface.  (If a tree is missing its lexical block decoration, GCC  
will use a binary search to identify the most probable lexical block  
when generating RTL.)  The existing (and reasonable!) LLVM ABI does  
not afford me that luxury, thus I've been fixing GCC.   BTW, I think  
clang is already generating correct lexical block info.

Did I answer your question?

stuart