Re: VTA merge - introduction

[Alexandre Oliva <aoliva at redhat dot com>]

On Jun  5, 2009, Ian Lance Taylor <iant@google.com> wrote:

> Alexandre Oliva <aoliva@redhat.com> writes:
>>> What is the typical size impact on debug information with VTA turned
>>> on?
>> 
>> I can get back to you with an answer, if you want, but I can tell you
>> that the answer may still be quite misleading at this point.

> I'm sure you can see that it is difficult to know just what to say
> when we don't know how much it will cost and we don't know how good
> the eventual results will be.

The âhow much it will costâ can be assessed right now.  Sorry if I
anything I said appeared to imply any different.

The âhow good it will beâ will be an incremental process.  What I can
offer today is a baseline already, that is significantly better than
what GCC does nowadays, not so much in terms of completeness, but
certainly in terms of correctness.

Improvements for completeness are going to follow as they're
implemented, and they're going to be limited to small changes in the
var-tracking pass and in debug output routines.

> Perhaps you could work toward minimizing your merge issues without
> committing the compiler as a whole to the VTA approach.  For example,
> perhaps we could accept DEBUG_INSN_P as an alias for INSN_P, and you
> could propose patches to change some code to use DEBUG_INSN_P where
> appropriate.

Err...  An alias for INSN_P wouldn't work, but alias to âfalseâ would.

But the fact that this could be changed right away, and that trivial
changes to the defininition of MAY_HAVE_DEBUG_STMTS/INSNS or of
var_debug_value_for_decl would already get that effect, mean the current
patches bring no greater commitment than the same changes with the
change you propose, no?

-- 
Alexandre Oliva, freedom fighter    http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist      Red Hat Brazil Compiler Engineer