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

[Martin Storsjö via llvm-dev]

On Fri, 26 Apr 2019, Tim Northover wrote:

> 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.

Yes, pretty much. Although I believe Wine's doesn't use much system 
functions of that sort.

>> 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.

Hmm, ok - that does indeed sound at least doable, at some level. Thanks 
for the insight and pointers!

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

Yes, I can imagine that.

I'm not necessarily running off to try to implement this right away; I'm 
trying to see what level of effort it'd require. For my own purposes my 
current solution of just backing it up and restoring on the windows<->wine 
boundary though. But that patch isn't making much headway upstream into 
Wine either, and it essentially means that Wine on arm64 (for running 
actual foreign windows binaries) only works for those who carry these out 
of tree patches along. (But for others, the current state of affairs is 
enough for building code with winelib.)

Anyway, thanks for your time!

// Martin