[llvm-dev] Nested ADJCALLSTACK UP/DOWN allowed?

[Shiva Chen via llvm-dev]

Hi Tim,

ADJCALLSTACKUP`s can't interleave probably because ADJCALLSTACKUP`s
may lower to SP adjustment instructions by
eliminateCallFramePseudoInstr when there exist variable sized objects.
Interleaving ADJCALLSTACKUP`s may cause the instructions accessing
variable sized objects with the incorrect offset.
So instruction scheduler creates CallResource artificial registers as
a glue to avoid interleaving while scheduling.
We encounter the same issue and find out that one of the
ADJCALLSTACKUP has been pre-scheduled by
PrescheduleNodesWithMultipleUses as you mention in
https://github.com/avr-rust/rust/issues/111#issuecomment-431603807.
The ADJCALLSTACKUP hoist too early in the code sequence and hold
CallResource too long which make other ADJCALLSTACKUP/DOWN can't be
scheduled. When there is no other nodes can be scheduled, the
scheduler will try to rename the register by creating copies, but
CallResource isn't a real register which triggers the error.
It seems that PrescheduleNodesWithMultipleUses is a heuristic
optimization method for better scheduling result, but hoisting
ADJCALLSTACKUP won't have benefit. There're several conditions that
PrescheduleNodesWithMultipleUses won't pre-schedule the node. I think
ADJCALLSTACKUP should be one of them because it will increase the
lifetime of CallResource. I have tried to push a patch on
https://reviews.llvm.org/D53485. Hopefully, it could be helpful.

Best,
Shiva
Tim Neumann via llvm-dev <llvm-dev at lists.llvm.org> 於 2018年10月22日 週一 上午5:51寫道：
>
> > The reason that brought me looking into the whole issue was some pattern getting turned into a compiler library call late. Back then I sidestepped the whole discussion by stopping to emit ADJCALLSTACK UP/DOWN of zero byte call frames (https://reviews.llvm.org/D42006) so they wouldn’t nest anymore for the helpers functions in question…
>
> Adding a similar patch to AVR fixes at least my minimizedreproduction,
> I haven't gotten around to trying it on other code yet.
>
> Thanks for all the info!
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev