[vta, vta4.4] merged with trunk and 4.4 @149247, updated VTA patchset

Richard Guenther richard.guenther@gmail.com
Thu Jul 9 07:05:00 GMT 2009


On Thu, Jul 9, 2009 at 3:36 AM, Alexandre Oliva<aoliva@redhat.com> wrote:
> On Jul  8, 2009, Richard Guenther <richard.guenther@gmail.com> wrote:
>
>> On Tue, Jul 7, 2009 at 10:17 PM, Alexandre Oliva<aoliva@redhat.com> wrote:
>>> On Jul  7, 2009, Richard Guenther <richard.guenther@gmail.com> wrote:
>>>> On Tue, Jul 7, 2009 at 11:10 AM, Alexandre Oliva<aoliva@redhat.com> wrote:
>
>>>>> Erhm...  Do you really want to *prevent* people from testing that VTA
>>>>> isn't causing codegen changes?  That's what removing this macro and code
>>>>> that tests it would accomplish.
>
>>>>> I thought you were only defending it to be enabled by default.  I'm fine
>>>>> with that, although I find it quite wasteful.  Even though the overhead
>>>>> of carrying and updating the notes is low, it's not zero.
>
>>>> Well, my main concern here is that if you can disable then people
>>>> can argue generating different code is a bug.
>
>>> I believe it should be regarded as a bug.  Different code means debug
>>> info is getting in the way of optimizations.  It shouldn't.
>
>> Uh, of course it is a "bug".  I just want to reduce the severity of the
>> bugs to optimization regressions from generating different code
>> with/without debug.
>
> If that was all, enabling it by default would suffice.  What you're
> suggesting is the removal of the ability to disable it, which goes much
> farther than that, and gets in the way of detecting and eliminating the
> optimization bugs.
>
>> Can you re-build Fedora with -fcompare-debug?
>
> I, personally, can't.  I (personally) don't have enough computing power
> and network bandwidth to do this, and I have no direct involvement with
> Fedora, so I can't tell whether their build machinery would support such
> a test, or whether I could use their infrastructure for this kind of
> test.
>
> However, I heard building all of Fedora would take something like a
> whole week, and that's assuming everything was known to compile with a
> 4.5ish compiler.
>
> That said, Fedora will probably do a mass rebuild with VTA if it gets
> into GCC soon enough.  I could try to get them to enable -fcompare-debug
> for the mass rebuild.  Of course, only if we don't follow your
> suggestion above, for it would render -fcompare-debug nearly useless.
>
>>> The workflow I have in mind is that, if some obscure error comes up in
>>> which recompiling with -g removes the error, -fcompare-debug can be used
>>> to confirm and fix this compiler bug, and then the obscure error will be
>>> debuggable with the aid of good debug information.
>
>> This doesn't help debugging in the field.
>
> But this does:
>
>>> Of course, if people are cutting corners, they can always compile with
>>> -g0 -fvar-tracking-assignments to work around any optimization
>>> differences.
>
> Conversely, they can compile with -g -fno-var-tracking-assignments and
> get (some) debug information while avoiding the codegen differences.
> Are you sure you want to remove the ability for people to do so?
>
>
>>> That said, we don't have machinery ATM to tell one from the other yet,
>>> i.e., to tell whether, given x => x_N, we should emit a modifiable or
>>> value-only location.  This is an improvement that's in my personal
>>> roadmap, and I have a few heuristics that can be used for this purpose.
>>>
>>>>> No, changing the DEF shouldn't call this adjust function.  This function
>>>>> is to be called when a DEF is moved or removed.
>>>
>>>> Hm, ok.  Can I have two wrappers around the main worker function
>>>> named accordingly?  Thanks.
>>>
>>> Err...  I'm sure you can, but I don't quite understand what you're
>>> getting at.  How would you like these wrappers to be named?
>
>> Like adjust_debug_stmts_for_ssa_name_release () and
>> adjust_debug_stmts_for_stmt_move ().  Note the tobb parameter
>> is redundant then - the target bb can be queried from the
>> stmt iterator specifying the target position.
>
> Aah, I think I see the distinction you're getting at now.  I pose
> (below) that it doesn't buy us anything.  AFAICT you're making the
> distinction expecting to bring about some other possibilities that just
> aren't there.

The main point is to improve readability (and thus maintainability)
of the use sites.

+  if (all && debug)
+    adjust_debug_stmts_for_var_def_move (name, NULL, NULL);

isn't exactly clear.  Much better is

  if (all && debug)
    adjust_debug_stmts_for_ssa_name_release (name);

you may be accustomed to your fancy overloads, I am not.  I guess
others aren't either.

>> Note that while adjust_debug_stmts_for_stmt_move can be done lazily
>
> Can it, really?
>
> The moved DEF could very well be modified to something incorrect before
> we get a chance to pick up the correct value, if we do it lazily.

IMHO we (usually) shouldn't modify the value assigned to an SSA name.
It for example renders points-to information attached to the name
incorrect.  Thus, each such case I could as well consider a bug.

> Or do you mean lazy removal only?  We can (and do) lazy removal, but
> limiting ourselves to only lazy removal causes significant loss of debug
> information.

I mainly think of lazy removal, yes.

Richard.

> --
> 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
>



More information about the Gcc-patches mailing list