This is the mail archive of the
mailing list for the GCC project.
Re: VTA merge - introduction
Alexandre Oliva <firstname.lastname@example.org> writes:
> 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 in correctness of the form "this variable is optimized out"
rather than printing garbage values are worth something, but they aren't
worth very much. It's not clear to me that the VTA patch is worth it if
that is the main improvement that we get. I know that we get more than
that, but how much more? And I know that more is coming, but for this
patch I would like to see significant improvements in debug information
before we commit to it, not after.
>> 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
> 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?
If things don't work out, it's relatively easy for us to rip out every
conditional on DEBUG_INSN_P. We can find them with grep and what to do
is obvious. Ripping out other changes may be more difficult. Obviously
we don't want to rip anything out, but I want to strike a balance
between being careful about the potential but perhaps unproven future
benefits of VTA and making your life easier during development.