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

Jump to bottom

[SR-6150] DLL storage is ignored for indirect runtime function invocation #48705

Closed
compnerd opened this issue Oct 13, 2017 · 3 comments
Closed

[SR-6150] DLL storage is ignored for indirect runtime function invocation #48705

compnerd opened this issue Oct 13, 2017 · 3 comments
Assignees
@compnerd
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself IRGen LLVM IR generation Windows Platform: Windows

Comments

@compnerd
Copy link
Collaborator

Previous ID SR-6150
Radar None
Original Reporter @compnerd
Type Bug
Status Resolved
Resolution Done
Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Bug, IRGen, Windows
Assignee @compnerd
Priority Medium

md5: 63598ed8ff1db991e60351a49d679fb5

Issue Description:

This breaks the SwiftOnoneSupport build as well as simple programs. More interestingly, the IR generated by swiftc fed to llc will generate the proper assembly, but swiftc will not generate the correct assembly.

IRGen in swift will annotate the appropriately DLL Storage to the variable, however, the backend will not perform the appropriate transformation. My guess is that since the attachment of MO_DLLIMPORT occurs normally in CodeGenPrepare which is not run by the swift LLVM pipeline, we are missing the attribute being attached to it.

This prevents the compilation of programs for the Windows targets.
@compnerd
Copy link
Collaborator Author

Had a quick look at this. This is with `-Onone` in my build, and the only differences in the pipeline is that the first pass is TTI rather than TLI. TLI is pushed below the `Assumption Cache Tracker` pass. We also do not run the `MachineDominator Tree Construction` and `Machine Natural Loop Construction` passes. The FastISel will fail due to the tail call, and fallback to the SDAG based ISel.

@compnerd
Copy link
Collaborator Author

I believe that this is due to the wrong CodeModel being pushed. I'll verify and push a change for this soon.

@compnerd
Copy link
Collaborator Author

This should be addressed by #12492

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@compnerd compnerd

Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself IRGen LLVM IR generation Windows Platform: Windows
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@compnerd