Re: Question on insn scheduling and SP

Re: Question on insn scheduling and SP

[Richard Kenner]

    Because they *don't* conflict with stack_pointer_rtx.
    Do read the thread Dale indicated.

I did, but some things aren't clear, at least in the comments that
were added.  What was added is a (clobber (mem)).  It's true that the
address was stack_pointer_rtx, but nothing in the comments suggest
that the form of the address is relevant.  Instead, they imply that
it was the mere addition of the CLOBBER that was sufficient.

Am I missing something?

Re: Question on insn scheduling and SP

[Richard Henderson]

On Tue, Oct 22, 2002 at 06:36:51AM -0400, Richard Kenner wrote:
> I did, but some things aren't clear, at least in the comments that
> were added.  What was added is a (clobber (mem)).  It's true that the
> address was stack_pointer_rtx, but nothing in the comments suggest
> that the form of the address is relevant.  Instead, they imply that
> it was the mere addition of the CLOBBER that was sufficient.
> 
> Am I missing something?

*Two* clobbers are necessary.

	(clobber (mem:BLK (scratch)))
	(clobber (mem:BLK stack_pointer_rtx))

The first has the magic form that conflicts with all memory,
the second contains a reference to the stack pointer.  Thus
the stack pointer adjustment depends on the second clobber,
the second clobber depends on the first clobber, and the
first clobber depends on all memory references.


r~

Re: Question on insn scheduling and SP

[Richard Henderson]

On Tue, Oct 22, 2002 at 01:24:33PM -0400, Richard Kenner wrote:
>     *Two* clobbers are necessary.
> 
> 	(clobber (mem:BLK (scratch)))
> 	(clobber (mem:BLK stack_pointer_rtx))
> 
>     The first has the magic form that conflicts with all memory,
>     the second contains a reference to the stack pointer.  Thus
>     the stack pointer adjustment depends on the second clobber,
>     the second clobber depends on the first clobber, and the
>     first clobber depends on all memory references.
> 
> Well if that's what's going on, why not keep it simpler and have the
> first clobber and then
> 	(use (stack_pointer_rtx))

Because the USE won't conflict with the first clobber.

And if you put them in a PARALLEL, then we're not using
the canonical "bare clobber" that is recognized in a
target-independent manner.


r~

Re: Question on insn scheduling and SP

[Richard Kenner]

    *Two* clobbers are necessary.

	(clobber (mem:BLK (scratch)))
	(clobber (mem:BLK stack_pointer_rtx))

    The first has the magic form that conflicts with all memory,
    the second contains a reference to the stack pointer.  Thus
    the stack pointer adjustment depends on the second clobber,
    the second clobber depends on the first clobber, and the
    first clobber depends on all memory references.

Well if that's what's going on, why not keep it simpler and have the
first clobber and then
	(use (stack_pointer_rtx))

Re: Question on insn scheduling and SP

[Richard Henderson]

On Mon, Oct 21, 2002 at 09:02:49PM -0400, Richard Kenner wrote:
> But there is already a reference to MEM in the case I'm looking at and
> I don't see the place in sched where it says that MEMs conflict with
> stack_pointer_rtx.

Because they *don't* conflict with stack_pointer_rtx.
Do read the thread Dale indicated.


r~

Re: Question on insn scheduling and SP

[Richard Kenner]

    I fixed it here:

    > http://gcc.gnu.org/ml/gcc-patches/2002-08/msg00838.html

    See also followups, I didn't get it right the first time:(

But there is already a reference to MEM in the case I'm looking at and
I don't see the place in sched where it says that MEMs conflict with
stack_pointer_rtx.

Re: Question on insn scheduling and SP

[Dale Johannesen]

On Monday, October 21, 2002, at 04:23  PM, Richard Kenner wrote:

> I can find no code to prevent an adjustment of the stack pointer (such 
> as
> when leaving a block containing variables allocated on the stack) wfrom
> being moved in front of the references to that memory.  Am I missing 
> something?
>
> If not, how can this be fixed?

I fixed it here:

> http://gcc.gnu.org/ml/gcc-patches/2002-08/msg00838.html

See also followups, I didn't get it right the first time:(

Question on insn scheduling and SP

[Richard Kenner]

I can find no code to prevent an adjustment of the stack pointer (such as
when leaving a block containing variables allocated on the stack) wfrom
being moved in front of the references to that memory.  Am I missing something?

If not, how can this be fixed?