-
-
Notifications
You must be signed in to change notification settings - Fork 609
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Posix x86_64 Calling conventions fixes #9013
Conversation
|
Thanks for your pull request and interest in making D better, @SSoulaimane! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please see CONTRIBUTING.md for more information. If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment. Bugzilla referencesYour PR doesn't reference any Bugzilla issue. If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog. Testing this PR locallyIf you don't have a local development environment setup, you can use Digger to test this PR: dub fetch digger
dub run digger -- build "master + dmd#9013" |
|
All test cases not related to this PR pass. Two tests fail |
|
Thanks! This will need to be squashed significantly before merge, but for now if you could squash the typo and minor mixup commits that would be great. |
|
What exactly is this doing? Changing DMD to not use its own calling conventions? |
|
this is for e: Incidentally this is a requisite for mapping |
Brilliant idea. I'm going trough this now It feels like doing surgery or writing a resume but it's a good thing to do. |
|
This will also need to enumerate the bugs that it fixes in one of the commit messages in order to close them, take a look at some the other bug fix PRs for that. |
|
All new public symbols should have Ddoc comments. |
|
Thank you @jacob-carlborg and @n8sh for you reviews about the new toArgTypes code. But I just pulled that code from this PR #8837 by @kinke whatever he decides there I'll just follow. these reviews should go to that PR. I don't know how to make this pull request dependent on that one here on github (if that's even possible?). |
Sure. I'll do that right after setting up some test cases first. |
8cdbca3 to
55c6695
Compare
|
Individual commits do make sense now after some reordering and squashing. The more significant commits are the older ones while the recent ones are mostly small fixes (that still make sense). |
|
This is extremely difficult to review because it does way too much. It should be done incementally in smaller steps. |
@WalterBright This is going to get reviewed by me irrespectively. I would recommend review-by-commit here.
While nice in principle, @SSoulaimane focus on getting all the tests to pass first. I'll deal with the fission of this for merge and review when the time comes. The restructuring you did of those commits is a good start. Thanks again for fixing these nasty bugs! |
Fixing |
… which is a SIMD vector
Other parts (mainly isReturnOnStack) don't yet match the windows 64 ABI.
allow a valid case where stackused == 1 the fpu stack may be preloaded in case the function call is the second operand to some binary operator example: `5 + fun()` ST(0) would be holding the constant 5 prior to executing funccall()
runnable/complex.d:test7581() breaks on assert(stackused == 0); This caused return values int ST0 not to be popped off the fpu stack when only the flags are needed (ex: comparison to zero).
…rray. Array operations will require moving the SIMD vector out of the SIMD register first.
DMD complains about global variable access from asm code
…argets" Just for CI's sake This reverts commit b4297b2.
When an if statement gets inlined into a comma expression and none of the if or else branches have a return statement then one of them may get removed by the optimizer which causes a type loss on the else branch. Q: Why does this matter? A: If the type is lost then the wrong registers will be allocated
…h mixed registers Use two new type flags for SROA `mTYxmmgpr` and `mTYgprxmm` Since I figured I don't really need the full type of the original aggregate preserved through optimization, but knowing which combination of registers to use is enough.
This was causing an ice in the backend
|
Rebooted at #10200. |
|
Why is this pr still open then? |
Make DMD adhere better to the platform native calling conventions on x86_64 posix targets