-
-
Notifications
You must be signed in to change notification settings - Fork 621
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
initial Aarch64 support #16554
initial Aarch64 support #16554
Conversation
Thanks for your pull request, @WalterBright! 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 run digger -- build "master + dmd#16554" |
4acce51
to
a8423cd
Compare
compiler/src/dmd/backend/x86/cod3.d
Outdated
import dmd.backend.code; | ||
import dmd.backend.arm.cod3; | ||
import dmd.backend.x86.code_x86; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can't see you getting far mixing different architectures like this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In case this comes across as an unactionable comment. To clarify, changes like this make it quite clear that a lot more work needs to go into separation of IR and target modules in the back-end before the introduction of any new architecture can be done (sans this kind of spaghetti imports).
That alone would make introducing any new foreign architecture into dmd more palatable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A good chunk of the code between the two will be identical. It's a balance between having them being totally separate and sharing common code. I don't know just where that balance will be, it will become apparent after I make more progress.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Having every architecture depend on every other architecture is not sustainable. Isn't contributing a new architecture hard enough without technical debt like this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It won't be clear where the separation should be until I make much more progress.
884e745
to
bff911e
Compare
5efb695
to
1f68251
Compare
How does disasm86.d, with its last commit 2 weeks ago, suddenly start failing the LDC Ubuntu run of its unittests?
|
0ce321e
to
1dfbe08
Compare
The LDC Ubuntu test is now working again, though I still have made no changes in that direction. |
c6ba646
to
80e33d8
Compare
The LDC Ubuntu is back to failing again. |
In target.d:
Looks wrong. |
16509ca
to
ec94ef1
Compare
@tgehr the process of setting those variables is an ugly tangle that I had only partially straightened out. I added an assert that it was set up correctly. |
P.S. I fixed the heisenbug in the disasm86 code. |
isX86 = !isX86_64;
assert(isX86 + isX86_64 + isAArch64 == 1); // there can be only one This assertion is equivalent to |
Only works for a trivial function:
void foo() { }
This is here mainly to ensure it stays in sync with the master branch as both evolve, and to not break the master.
Added undocumented
-arm
command line switch to enable it.