[llvm-dev] Automatically backing up and restoring x18 around function calls on AArch64?

Tim Northover via llvm-dev llvm-dev at lists.llvm.org
Fri Apr 26 06:15:41 PDT 2019


Hi Martin,

On Fri, 26 Apr 2019 at 13:30, Martin Storsjö via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> Another idea which was raised in
> https://bugs.winehq.org/show_bug.cgi?id=38780#c13, which disucsses this
> matter, was if it would be possible to make Clang/LLVM always back up and
> restore x18 on any call to any other function, to make sure that the
> register maintains the right value as long as running in Wine code.

You're still pretty much screwed if you call qsort with a windows
callback (or any equivalent but more convoluted situation), aren't
you? I suppose you'd have to surround any top-level callback passed
into non-compliant code with an x18-thunk.

> I didn't really find any straighforward way of starting to implement this
> however. Does anyone here happen to have ideas about how one could either
> implement this, or solve it in another way?

At a high level what you probably need to do is get x18 copied on
function entry and propagated into every call (or, better, every call
to a Windows function). Since it's all implicit the place to modify is
AArch64ISelLowering.cpp.

LowerFormalArguments could do a CopyFromReg to preserve the value on
function entry, and probably CopyToReg it into a new virtual register
so that other basic blocks can access it (via
MachineRegisterInfo::createVirtualRegister). You'd save the value of
this virtual register somewhere for later (in
AArch64MachineFunctionInfo probably).

LowerCall would then CopyToReg from that vreg andput it back into x18,
then mark the call as using that register. (using the RegsToPass
variable, or equivalent). Since you know which functions need x18, you
can be specific there.

LowerReturn probably also needs to "return" it in x18 too, though you
might handle that side by making it callee-saved instead.

I've not tested any of this, BTW. And upstreaming it would likely be
controversial.

Cheers.

Tim.


More information about the llvm-dev mailing list