Sorry, to be clearer, what I meant by:
> From: Paul Schlie <[EMAIL PROTECTED]>
> .. (thereby the pseudo is now equated with the spilled value), or ...
was: (thereby the pseudo is now equated with an allocated temporary
memory location, now storing the spilled value), or ...
> Jeffrey A Law wrote:
> ...
> But what worries me even more is spilling. Say a pseudo has a hard reg
> assigned and is also equivalent to a readonly memory location. Reload
> then decides to spill the pseudo out of the hard reg because the hard
> reg was needed for something else. When that occ
On Wed, 2005-04-20 at 18:51 +0200, Eric Botcazou wrote:
> > Yes, I meant SET_DEST. Do you see how if a SET_DEST is a pseudo
> > which did not get a hard register and is equivalent to a readonly
> > memory location that the insn is useless?
>
> Yes, I think so: being equivalenced implies that ther
> Yes, I meant SET_DEST. Do you see how if a SET_DEST is a pseudo
> which did not get a hard register and is equivalent to a readonly
> memory location that the insn is useless?
Yes, I think so: being equivalenced implies that there was a REG_EQUIV note,
so the insn cannot do anything else than
On Wed, 2005-04-20 at 17:18 +0200, Eric Botcazou wrote:
> > Think about it for a while -- given a SET where the SET_SRC is a
> > pseudo which did not get a hard register and is equivalenced to
> > a read-only memory location, then the SET must be dead as it
> > can only be setting the memory locati
> Think about it for a while -- given a SET where the SET_SRC is a
> pseudo which did not get a hard register and is equivalenced to
> a read-only memory location, then the SET must be dead as it
> can only be setting the memory location to the value already
> in the memory location.
Was that long
On Tue, 2005-04-19 at 21:36 +0200, Eric Botcazou wrote:
> > > For 3.3 and 3.4, this was "fixed" by not recording memory equivalences
> > > that have the infamous RTX_UNCHANGING_P flag set.
> >
> > Also a possibility. Making the equivalent change (!MEM_READONLY_P)
> > appears to do the trick for ma
> > For 3.3 and 3.4, this was "fixed" by not recording memory equivalences
> > that have the infamous RTX_UNCHANGING_P flag set.
>
> Also a possibility. Making the equivalent change (!MEM_READONLY_P)
> appears to do the trick for mainline.
Yes, but that's of course not optimal, unnecessary spills
> From: Paul Schlie <[EMAIL PROTECTED]>
>
> some-const-char*-funct("abc"); // "C.x[4] = {'a','b','c',0} array
>// of "literal static const data"
>// some-const-char*-funct(C.x);
Or rather I suspect it implies the allocation of a temp
> Eric Botcazou writes:
>> Jeffrey A Law writes:
>> ...
>> Which faults because the memory location is actually read-only memory.
>
> PR rtl-optimization/15248.
>
>> What's not clear to me is how best to fix this.
>>
>> We could try to delete all assignments to pseudos which are equivalent
>> to M
On Tue, 2005-04-19 at 08:49 +0200, Eric Botcazou wrote:
> > So the combination of the TCB merge plus the pending jump threading
> > changes apparently has ticked a reload bug which manifests itself with
> > the stage1 compiler mis-compiling the stage2 compiler.
> >
> > [...]
> >
> > Which faults be
> So the combination of the TCB merge plus the pending jump threading
> changes apparently has ticked a reload bug which manifests itself with
> the stage1 compiler mis-compiling the stage2 compiler.
>
> [...]
>
> Which faults because the memory location is actually read-only memory.
PR rtl-optim
So the combination of the TCB merge plus the pending jump threading
changes apparently has ticked a reload bug which manifests itself with
the stage1 compiler mis-compiling the stage2 compiler.
Upon entry into local-alloc we have the following key insns:
(insn:HI 88 85 89 10 (set (reg:QI 66 [ D.
13 matches
Mail list logo
