Only parse body of restricted function when compiling in restricted context #144
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
@scchan I wouldn't mind it, if only to avoid posthumous whinging:) |
|
@scchan I believe you want to consider this in the context of the memory consumption work. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
At the moment we still parse and semantically analyse the body of a [[cpu]] only restricted function when compiling for accelerator or, conversely, a [[hc]] only function when compiling for host. This can lead to subtle issues when e.g. using AMDGCN builtins. This avoids that behaviour by way of eviscerating functions who are in this situation, thus retaining their impact on mangling whilst not exposing guts that are target specific. The suggested solution appears reasonable, if rather yucktastic in terms of the amount of code (an alternative would be to skip such declarations completely, but that may be surprising in terms of mangling across targets); I'd be happy if anyone had a better / cleaner solution. Thanks to @sameerds for discovering this.