Fix M1 tail call issue when building

[gbaraldi]

This implements @staticfloat solution for the LLVM error that appears on m1 builds #44107.
Current master is very brittle when building the m1 but this bug happens every time without the PR.
I tried debugging it quite a lot and LLVM DEBUG with arm lower call debug on doesn't show why it doesn't tail call so I have no idea why it fails, the bug was added by the purity PR as mentioned in the issue. I don't know if it has to do with the anonymous union but apple gives a warning for that

[navidcy]

This works on my MacBook Pro M1 Max.

[navidcy]

               _
   _       _ _(_)_     |  Documentation: https://docs.julialang.org
  (_)     | (_) (_)    |
   _ _   _| |_  __ _   |  Type "?" for help, "]?" for Pkg help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 1.9.0-DEV.35 (2022-02-20)
 _/ |\__'_|_|_|\__'_|  |  fix-m1-build/e102b5caaf (fork: 63 commits, 5 days)
|__/                   |

[vtjnash]

possible improvement?

Suggested change

	// Known failures includes vararg (not needed here) and sret.
	// Known failures includes vararg (not needed here) and sret.
	ret->setTailCall();

Is this only M1, or all AArch64?

[gbaraldi]

This is m1 only. I wonder if it's this https://github.com/llvm/llvm-project/blob/d1cd64ffdd832220dbe1829c2f09b880be67be31/llvm/test/CodeGen/AArch64/GlobalISel/call-translator-musttail.ll, this is the only aarch64-apple exclusive thing related to musttail.

That might be a more robust solution for sure. Does doing the ccall as a tail call have some performance benefit?

[gbaraldi]

I found what causes musttail to fail, it's that the stack arguments of the call don't fit into the save area for the callee. https://github.com/gbaraldi/llvm-project/blob/5be8ea4bd7b0d66214c22033a7fd298544e65027/llvm/lib/Target/AArch64/AArch64ISelLowering.cpp#L5702-L5707. Not sure if it's something to be worried or not however.

[KristofferC]

I'll merge this now since it fixes the build and we want this for 1.8-beta to be available on M1. #44279 (comment) can be discussed further and possible improvements can be done in future PRs.

[ngam]

@KristofferC, I recommend you keep track of @gbaraldi investigation somewhere to ensure the work doesn't get lost. Yes, merging it is fine and preferable --- thanks for that! But maybe open a new issue to keep track of all the development. (Maybe @gbaraldi can do that?)

Thanks a lot for the great work!!

[gbaraldi]

I will open an issue to keep this is mind, this is is a consequence of the purity PR, there are some other issues related to it too so I might open a more general issue.

edit: issue opened #44314