My recent patch for PR48866, that introduced dead_debug_insert_temp()
with DEBUG_TEMP_BEFORE_WITH_VALUE as a possibility for keeping
expressions about to be DCE'd, caused regressions on ppc because it
would take MEMs with autoinc addressing modes, which would be rejected
down the road.
This patch
Il 13/04/2012 17:58, Alexandre Oliva ha scritto:
>
> I've just installed the patch, but if you find the need for any further
> improvement, let me know and I'll do it right away.
I wonder if it makes any sense to move the dead_debug_* stuff to its own
file...
Paolo
On Apr 9, 2012, Eric Botcazou wrote:
> Could you add a comment for each value?
Done
> Missing "extern" for all declarations.
Thanks, added.
> I don't understand the "or _WITH_VALUE otherwise" part of the comment.
Sorry, my bad. It didn't make sense. Fixed.
> Please add a comment explaini
> Some more context here: this enables DCE to turn removed insns into
> debug temps when they're useful for debug info. It further improves
> debug info quality when installed along with the patch I just posted for
> PR 48866. Without it, a number of chains of debug temps that lead to a
> real in
On Jun 6, 2011, Alexandre Oliva wrote:
> On Jun 6, 2011, Eric Botcazou wrote:
>>> It might be too late for DF to do anything sensible to preserve the
>>> debug info rather than just throw it away, as your partial approval
>>> suggests.
>> OK, let me think about this a little more.
Ping?
> H
On Jun 6, 2011, Eric Botcazou wrote:
>> It might be too late for DF to do anything sensible to preserve the
>> debug info rather than just throw it away, as your partial approval
>> suggests.
> OK, let me think about this a little more.
>> Indeed, sorry, I misread it.
> Mind installing these
On Jun 6, 2011, Eric Botcazou wrote:
>> Indeed, sorry, I misread it.
> Mind installing these bits separately?
Nope. Testing it separately now.
> My understanding is that they are
> independent correctness fixes.
Yeah, I guess they are. They won't make debug info any worse, although
they m
> It might be too late for DF to do anything sensible to preserve the
> debug info rather than just throw it away, as your partial approval
> suggests.
OK, let me think about this a little more.
> Indeed, sorry, I misread it.
Mind installing these bits separately? My understanding is that they
On Jun 3, 2011, Eric Botcazou wrote:
> Does the same logic need to be replicated in all passes that do? On
> the other hand, these passes call into DF when they remove insns, so
> DF is a central place here.
I went over (again?) a number of passes that call delete_insn directly
or indirectly.
On Mon, Jun 06, 2011 at 02:32:29AM -0300, Alexandre Oliva wrote:
> Those that remove sets whose DESTs may still be receved by debug insns
> ought to adjust debug insns, yeah. I think (hope) we have them all
> covered. Do you know of any we missed?
delete_trivially_dead_insns is already covered,
On Jun 3, 2011, Eric Botcazou wrote:
>> Hmm... Maybe it could, I'm not sure. The problem is that DCE removes
>> insns, and then DF associates remaining uses in debug insns to earlier
>> DEFs. Adjusting debug insns in DCE is right per the VTA design motto:
>> decide as if debug insns weren't t
> Hmm... Maybe it could, I'm not sure. The problem is that DCE removes
> insns, and then DF associates remaining uses in debug insns to earlier
> DEFs. Adjusting debug insns in DCE is right per the VTA design motto:
> decide as if debug insns weren't there, adjust them as you would adjust
> non-
On Jun 2, 2011, Eric Botcazou wrote:
> Why can't the problem be addressed purely within DF?
Hmm... Maybe it could, I'm not sure. The problem is that DCE removes
insns, and then DF associates remaining uses in debug insns to earlier
DEFs. Adjusting debug insns in DCE is right per the VTA desi
> One of the issues was that DCE removed an insn that set a REG in a
> certain mode, without adjusting a debug use of that REG. This was in
> libstdc++, but I failed to take note of the affected file. DF later
> attached that debug use to another SET to the same REG in a different,
> incompatible
The insn shuffling in one of my patches for PR48866 shook out some
latent problems in DCE.
One of the issues was that DCE removed an insn that set a REG in a
certain mode, without adjusting a debug use of that REG. This was in
libstdc++, but I failed to take note of the affected file. DF later
a
15 matches
Mail list logo
