[llvm-dev] What is stack pointer adjustment on scheduling?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[llvm-dev] What is stack pointer adjustment on scheduling?

Sudhindra kulkarni via llvm-dev
Hi there,

I'm planning to implement a prototype about scheduling across calls in
LLVM as my school project. When I look into MachineScheduler.cpp, I
found this piece of comments for `isSchedBoundary`:

 > MachineScheduler does not currently support scheduling across calls.
 > To handle calls, the DAG builder needs to be modified to create
 > register anti/output dependencies on the registers clobbered by the
 > call's regmask operand. In PreRA scheduling, the stack pointer
 > adjustment already prevents scheduling across calls. In PostRA
 > scheduling, we need the isCall to enforce the boundary, but there
 > would be no benefit to postRA scheduling across calls this late
 > anyway.

What I'm not sure about is the 'stack pointer adjustment'. What is it?
Is it the stack protector or some stuff about the calling convention?
And how does it prevents scheduling across calls?

Thanks,

Chaofan
_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] What is stack pointer adjustment on scheduling?

Sudhindra kulkarni via llvm-dev
Hi Chaofan,

On Tue, 16 Apr 2019 at 16:27, Qiu Chaofan via llvm-dev
<[hidden email]> wrote:
> What I'm not sure about is the 'stack pointer adjustment'. What is it?

I'm not certain, but my best guess is that it's referring to the
instructions most targets call "ADJCALLSTACKDOWN" and
"ADJCALLSTACKUP". They are defined within each target, and surround
any call sequence to tell the code allocating stack slots how much is
needed for that call's parameters. They're marked as using and
defining SP.

> And how does it prevents scheduling across calls?

Mechanically, it's through the call to TLI.isSchedulingBoundary, which
disallows any instruction that modifies SP. The reasoning is explained
a little more in the body of TargetInstrInfo::isSchedulingBoundary,
and makes it sound like simply opening that up without thought
wouldn't be a great idea.

Cheers.

Tim.
_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev