Skip to content
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

Closed
wants to merge 35 commits into from

Conversation

SSoulaimane
Copy link
Member

Make DMD adhere better to the platform native calling conventions on x86_64 posix targets

@dlang-bot
Copy link
Contributor

dlang-bot commented Nov 25, 2018

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 verify that your PR follows this checklist:

  • My PR is fully covered with tests (you can see the coverage diff by visiting the details link of the codecov check)
  • My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
  • I have provided a detailed rationale explaining my changes
  • New or modified functions have Ddoc comments (with Params: and Returns:)

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 references

Your 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 locally

If 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"

@SSoulaimane
Copy link
Member Author

All test cases not related to this PR pass. Two tests fail testargtypes.d and testabi.d which I'm working on now. I did hand checks though. This isn't ready for merge yet but it's ready for a review.

README.md Outdated Show resolved Hide resolved
src/dmd/backend/ty.d Outdated Show resolved Hide resolved
src/dmd/e2ir.d Outdated Show resolved Hide resolved
src/dmd/globals.d Outdated Show resolved Hide resolved
@thewilsonator
Copy link
Contributor

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.

@jacob-carlborg
Copy link
Contributor

What exactly is this doing? Changing DMD to not use its own calling conventions?

@thewilsonator
Copy link
Contributor

thewilsonator commented Nov 26, 2018

this is for extern(C[++]), the current posix x64 ABI is broken, this fixes it.

e: Incidentally this is a requisite for mapping T[] to C++.

src/dmd/globals.d Outdated Show resolved Hide resolved
src/dmd/target.d Outdated Show resolved Hide resolved
@SSoulaimane
Copy link
Member Author

SSoulaimane commented Nov 27, 2018

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.

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.

@thewilsonator
Copy link
Contributor

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.

src/dmd/argtypes.d Outdated Show resolved Hide resolved
@jacob-carlborg
Copy link
Contributor

All new public symbols should have Ddoc comments.

@SSoulaimane
Copy link
Member Author

SSoulaimane commented Nov 27, 2018

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

@SSoulaimane
Copy link
Member Author

SSoulaimane commented Nov 27, 2018

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.

Sure. I'll do that right after setting up some test cases first.

@SSoulaimane
Copy link
Member Author

SSoulaimane commented Nov 27, 2018

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

@WalterBright
Copy link
Member

This is extremely difficult to review because it does way too much. It should be done incementally in smaller steps.

@thewilsonator
Copy link
Contributor

thewilsonator commented Nov 28, 2018

This is extremely difficult to review because it does way too much.

@WalterBright This is going to get reviewed by me irrespectively. I would recommend review-by-commit here.

It should be done incementally in smaller steps.

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!

@kinke
Copy link
Contributor

kinke commented Nov 29, 2018

Two tests fail testargtypes.d and testabi.d

Fixing testargtypes.d is trivial, just get rid of all version (DigitalMars) blocks. These are cases where the old toArgTypes() for 64-bit targets diverges from the new toArgTypes_sysv_x64() one.

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
@SSoulaimane
Copy link
Member Author

Rebooted at #10200.

@12345swordy
Copy link
Contributor

Why is this pr still open then?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants