This is an archive of the discontinued LLVM Phabricator instance.

[AArch64] Treat x18 as callee-saved in functions with Windows calling convention on Darwin
ClosedPublic

Authored by dzhidzhoev on Jul 27 2022, 5:37 PM.

Details

Summary

rGcf97e0ec42b8 makes $x18 to be treated as callee-saved in functions with
Windows calling convention on non-Windows OSes.

Here we mark $x18 as callee-saved for functions with Windows calling
convention on Darwin, as well as on other non-Windows platforms, in
order to prevent some miscompilations (like miscompilation of
win64cc-darwin-backup-x18.ll).

Since getCalleeSavedRegs doesn't return x18 in list of callee-saved
registers, assignCalleeSavedSpillSlots and determineCalleeSaves
consider different sets of registers as callee-saved. It causes an
error:

Assertion failed: ((!HasCalleeSavedStackSize || getCalleeSavedStackSize() == Size) && "Invalid size calculated for callee saves"), function getCalleeSavedStackSize, file 
AArch64MachineFunctionInfo.h, line 292.

Diff Detail

Event Timeline

dzhidzhoev created this revision.Jul 27 2022, 5:37 PM
Herald added a project: Restricted Project. · View Herald TranscriptJul 27 2022, 5:37 PM
dzhidzhoev requested review of this revision.Jul 27 2022, 5:37 PM
Herald added a project: Restricted Project. · View Herald TranscriptJul 27 2022, 5:37 PM

I think this looks reasonable, but I’ll have a closer read later.

Where did you trigger this issue - by building Wine on macOS? (I did try building Wine on macOS/arm64 in 2020, and the logic for backing up x18 landed in 2019, so I wonder why I didn’t notice this issue… Maybe the Xcode clang didn’t contain that change yet at that point, or maybe it’s not noticed or the compiler is built without assertions?)

FWIW, with a recent refactoring in Wine, where a proper syscall interface is used between windows code and the native unix code, I think the whole mechanism for backing up/restoring x18 might be unnecessary, so we could consider ripping it out altogether too. I guess I could run some tests to see what the current state is…

Where did you trigger this issue - by building Wine on macOS? (I did try building Wine on macOS/arm64 in 2020, and the logic for backing up x18 landed in 2019, so I wonder why I didn’t notice this issue… Maybe the Xcode clang didn’t contain that change yet at that point, or maybe it’s not noticed or the compiler is built without assertions?)

I was trying to investigate this issue https://github.com/llvm/llvm-project/issues/54079 and have found that the source code that doesn't compile with GlobalISel don't compile with SelectionDAG too, with debug clang build.

FWIW, with a recent refactoring in Wine, where a proper syscall interface is used between windows code and the native unix code, I think the whole mechanism for backing up/restoring x18 might be unnecessary, so we could consider ripping it out altogether too. I guess I could run some tests to see what the current state is…

TBH I'm not familiar with running Windows code on Darwin, so I would appreciate your feedback.

mstorsjo accepted this revision.Aug 2 2022, 5:04 AM

LGTM, thanks!

In practice, Wine works mostly quite well without this compiler help feature now, so we could consider removing the whole concept of extra backup of x18 on non-Windows platforms sometime in the future too, but I think it's best to wait until Wine has completed their transition to split all code that calls into host libraries behind a syscall interface (aka the PE split).

This revision is now accepted and ready to land.Aug 2 2022, 5:04 AM
This revision was landed with ongoing or failed builds.Aug 2 2022, 10:34 AM
This revision was automatically updated to reflect the committed changes.