Skip to content

Improve support in Swift for program address space N in llvm DataLayout #74817

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

Closed

Conversation

carlos4242
Copy link
Contributor

@rauhul @phausler @kubamracek

[AVR Harvard Architecture fixes]: Update Swift, at least partially, to be aware of address spaces for functions:

I think the AVR target might struggle to produce code without these fixes in many cases. Simple code is OK on AVR but things like function pointers will probably need this. I'm completely open to any other way of supporting this too.

  • For closures, allow round trip via opaque ptr in pgmspace.
  • Fix for mapping program space functions into protocol witness tables and value witness tables.
  • Fixed in SIL function lowering, addPointerParameter should only create pointers in address space 1 when the parameter is a function (e.g. working with closures).
  • Fix coroutine/yield emission.
  • More program address space fixes.
  • Fix pointer wrangling between address spaces (or not) in coroutine emission.
  • Fix pointer parameter wrangling between namespaces in call site emission.

…o be aware of address spaces for functions:

- For closures, allow round trip via opaque ptr in pgmspace.
- Fix for mapping program space functions into protocol witness tables and value witness tables.
- Fixed in SIL function lowering, addPointerParameter should only create pointers in address space 1 when the parameter is a function (e.g. working with closures).
- Fix coroutine/yield emission.
- More program address space fixes.
- Fix pointer wrangling between address spaces (or not) in coroutine emission.
- Fix pointer parameter wrangling between namespaces in call site emission.
@rauhul rauhul mentioned this pull request Jul 2, 2024
9 tasks
@kubamracek
Copy link
Contributor

Let's first bring up the AVR target support so that the compiler at least accepts it for compilation, I'll write down how to get to that in #74818. Let's revisit this afterwards.

@kubamracek
Copy link
Contributor

Hey @rjmccall, @DougGregor, @aschwaighofer, @eeckstein,

@carlos4242 has merged some basic AVR groundwork and 16-bit stdlib code fixes, and the contents of this PR is what's next on the list towards being able to produce AVR code. The obvious missing piece in this draft is tests, but ignoring that for a second, would you mind taking a look and advising whether this approach in this draft makes sense, and that this is roughly the direction we're looking for?

@carlos4242
Copy link
Contributor Author

I think it's time to close this. We can address it in other PRs. The source branch is always available anyway.

@carlos4242 carlos4242 closed this Jan 2, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants