It could be the case that an alternate, legitimate representation of the
same expression is used elsewhere, and at the point that goes into
cselib, the previously debug-only entry should become a regular entry in
the cselib table.
Is this what you observe?
Sure, that's what I've been saying
On Mar 9, 2012, Eric Botcazou ebotca...@adacore.com wrote:
It does that only in case the -g0 build would add the same locs to the
table. Only the DEBUG_INSN_P setting_insn locs are there just in -g builds
and not in -g0 ones.
If that's really supposed to work like so, then this is the bug,
I'd say that alias.c when processing non-debug insn content should just
ignore any cselib locs which have DEBUG_INSN_P setting_insn.
That wouldn't work though, as promote_debug_loc overwrites setting_insn.
--
Eric Botcazou
On Fri, Mar 09, 2012 at 08:05:39PM +0100, Eric Botcazou wrote:
I'd say that alias.c when processing non-debug insn content should just
ignore any cselib locs which have DEBUG_INSN_P setting_insn.
That wouldn't work though, as promote_debug_loc overwrites setting_insn.
It does that only in
It does that only in case the -g0 build would add the same locs to the
table. Only the DEBUG_INSN_P setting_insn locs are there just in -g builds
and not in -g0 ones.
If that's really supposed to work like so, then this is the bug, because the
non-legitimate expression is present only with
On Tue, Mar 6, 2012 at 11:08 PM, Eric Botcazou ebotca...@adacore.com wrote:
If you try to bootstrap the GNAT 4.7.0 compiler on IA-64/Linux with
non-default
options (-gnatpg replaced with -gnatpgn), you get another comparison failure
caused by debug insns, stemming from the machine-specific
On Wed, Mar 07, 2012 at 10:27:22AM +0100, Richard Guenther wrote:
On Tue, Mar 6, 2012 at 11:08 PM, Eric Botcazou ebotca...@adacore.com wrote:
If you try to bootstrap the GNAT 4.7.0 compiler on IA-64/Linux with
non-default
options (-gnatpg replaced with -gnatpgn), you get another comparison
On Wed, Mar 7, 2012 at 10:35 AM, Jakub Jelinek ja...@redhat.com wrote:
On Wed, Mar 07, 2012 at 10:27:22AM +0100, Richard Guenther wrote:
On Tue, Mar 6, 2012 at 11:08 PM, Eric Botcazou ebotca...@adacore.com wrote:
If you try to bootstrap the GNAT 4.7.0 compiler on IA-64/Linux with
On Wed, Mar 07, 2012 at 11:01:36AM +0100, Richard Guenther wrote:
Hmm, but then this complicates and slows down the generic alias machinery.
Of course IMHO the RTL alias machinery should be conservative with respect
to what the RTL IL allows - so the question is are non-legitimate addresses
Hmm, but isn't the bug that we feed debug-insn mems to memrefs_conflict_p?
We don't. The addresses come from regular insns, but cselib is able to
equivalence one of them with an address that is already in its hashtable
because of a debug insn (see cselib.c:promote_debug_loc).
Or that we
CCing Alex. I think we feed debug insn mems in the scheduler to be able to
find out what debug insns need to be invalidated and what can be kept.
And any address expressions are legitimate for debug insns, why should we
be limited by what the ISA allows? All we are limited is if we can
11 matches
Mail list logo
