This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: LTO, LLVM, etc.


On Tuesday 06 December 2005 00:23, Jim Blandy wrote:
> Debug information describes two things: (...snip...)
> Keeping the two representations separate (which I could easily 
> see being beneficial for optimization) shifts that burden onto some
> new party which isn't being discussed, and which will be quite
> complicated.

Uh, I'm not sure what you're trying to say, but it looks like you're
missing the point.

Both the source level representation and the optimizer representation
have to represent debug information somehow.  Nobody is shifting any
burden anywhere.


For the source level, we'd have debug information in whatever kind
of data structures the front ends would be using.  In the front ends,
you want to store everything that is needed to represent the source
code as accurately as possible.  So you could have information about
class hierarchy, templates, inheritance, and so on, at this level.

But most of that information is not useful for source level debuggers
(e.g. gdb) at all.  So this detailed source level information doesn't
have to survive in the translation from the front end representation
to the optimizer's representation.

For the optimizers, you'd translate all the relevant debug stuff along
with everything else to something suitable for the optimizers: Line
number information, symbol tables, what variable goes in what register
or stack slot, etc.
Some of these things, you don't even _want_ to represent at the source
level (e.g. what is a stack slot in C++ source code? It's meaningless).


What makes EDG so great is that it represents C++ far closer to the
actual source code than G++ does.  It would be good for G++ to have
a representation that is closer to the source code than what it has
now.

The problem with using the same data structures (i.e. 'tree') for the
very-close-to-language representation and the optimizer representation
is that the two representation have completely different goals, as
Chris Lattner already explained.
I'd be surprised if there a compiler exists that runs optimizations
on EDG's C++ specific representation. I think all compilers that use
EDG translate EDG's representation to a more low-level representation.

What I'd like for GCC is to have a similar separation of front-end and
middle-end/back-end representation, instead of "everything-is-a-tree".
If that means writing two intermediate representation dumpers, tough.
It would be worth it.

Gr.
Steven


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]