Re: VTA merge?

[Richard Guenther <richard dot guenther at gmail dot com>]

On Fri, Jun 5, 2009 at 12:53 PM, Alexandre Oliva <aoliva@redhat.com> wrote:
> On Jun ?5, 2009, Richard Guenther <richard.guenther@gmail.com> wrote:
>
>> So if I understand the above right then VTA is a new source of
>> code-generation differences with -g vs. -g0.
>
> It was, but that was before I spent several months stopping it from
> being it ;-)

Obviously ;)

> And once VTA is on and bootstrap-debug is the rule rather than the
> exception (with RTH's suggestion, it will again be faster than normal
> bootstrap, and catch even some regressions that current
> BUILD_CONFIG=bootstrap-debug doesn't), it won't be just me catching and
> fixing these ;-)

IMHO we should make bootstrap-debug (that's the one building
stage2 w/o debug info and stage3 with debug info, correct?) the
default regardless of VTA going in or not.  If it works on the
primary and secondary targets of course ;)

Can you submit a separate patch to do so? (maybe you did already)

> FTR, in the last two or three merges, I've had more -fcompare-debug
> regressions with VTA disabled than with it enabled. ?Perhaps we should
> default to BUILD_CONFIG=bootstrap-debug? ?It would be a start, but it
> wouldn't have caught all of the recent regressions. ?Some of them only
> affected C++ and Ada testcases, and bootstrap-debug won't catch these.
> It takes -fcompare-debug for the testsuite run or something equivalent
> to do so.

bootstrap-debug by default would be a start.

Honestly I don't care too much about -g vs. -g0 differences as we
build everything with -g and strip debug info later.  But passing
bootstrap-debug is a release goal that I will support.

> Hopefully people who run automated testers can be talked into using the
> -fcompare-debug option for the library builds and testsuite runs.
>
>> IMHO a much more convincing way to avoid code generation
>> differences with -g vs. -g0 and VTA would be to _always_ have
>> the debug statements/instructions around, regardless of -g/-g0
>
> That's an option I haven't discarded, but I wouldn't be able to claim
> VTA had zero cost when disabled if that was so.

So what is the overhead of having the debug stmts/insns if you
throw them away before var-tracking and do debug info the old way?

Thanks,
Richard.