> 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 s
On Mar 9, 2012, Eric Botcazou 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, because the
>
> 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 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 onl
> 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
> 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 ex
> 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 ha
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
>
On Wed, Mar 7, 2012 at 10:35 AM, Jakub Jelinek 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 wrote:
>> > If you try to bootstrap the GNAT 4.7.0 compiler on IA-64/Linux with
>> > non-default
>> > options (-gnatpg repla
On Wed, Mar 07, 2012 at 10:27:22AM +0100, Richard Guenther wrote:
> On Tue, Mar 6, 2012 at 11:08 PM, Eric Botcazou 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
> > ca
On Tue, Mar 6, 2012 at 11:08 PM, Eric Botcazou 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 reorg pass (aka insn
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 reorg pass (aka insn
bundling on IA-64). With -g , when cselib is called on:
(i
12 matches
Mail list logo
