[flang] handle indirect module variable use in internal procedure #65324
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
When a module variable is referenced inside an internal procedure, but the use statement for the module is inside the host, semantics may not create any symbols with HostAssocDetails directly under the internal procedure scope. So pft::getScopeVariableList, that is called in the bridge when lowering the internal procedure scope, failed to instantiate the module variables. This lead to "symbol is not mapped to any IR value" compile time errors. This patch fixes the issue by adding the variables to the list of "captured" global variables from the host program, so that they are instantiated as part of the `internalProcedureBindings` in the bridge. The rational of doing it that way instead of changing getScopeVariableList is that getScopeVariableList would have to import all the module variables used inside the host since it cannot know which ones are used inside the internal procedure from the Scope information. The fix in this patch only instantiates the module variables from the host that are actually referenced inside the internal procedure.
|
Looks good to me. I don't see an approve button to click here. |
"Add your review" -> "Review changes" -> "Approve" generates a "Looks like something went wrong" message |
I get the same error when trying to approve. |
vzakhari
approved these changes
Sep 5, 2023
vdonaldson
approved these changes
Sep 5, 2023
clementval
approved these changes
Sep 5, 2023
avillega
pushed a commit
to avillega/llvm-project
that referenced
this pull request
Sep 11, 2023
…vm#65324) When a module variable is referenced inside an internal procedure, but the use statement for the module is inside the host, semantics may not create any symbols with HostAssocDetails directly under the internal procedure scope. So pft::getScopeVariableList, that is called in the bridge when lowering the internal procedure scope, failed to instantiate the module variables. This lead to "symbol is not mapped to any IR value" compile time errors. This patch fixes the issue by adding the variables to the list of "captured" global variables from the host program, so that they are instantiated as part of the `internalProcedureBindings` in the bridge. The rational of doing it that way instead of changing `getScopeVariableList` is that `getScopeVariableList` would have to import all the module variables used inside the host since it cannot know which ones are referenced inside the internal procedure from the semantics::Scope information. The fix in this patch only instantiates the module variables from the host that are actually referenced inside the internal procedure.
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.
When a module variable is referenced inside an internal procedure, but the use statement for the module is inside the host, semantics may not create any symbols with HostAssocDetails directly under the internal procedure scope.
So pft::getScopeVariableList, that is called in the bridge when lowering the internal procedure scope, failed to instantiate the module variables. This lead to "symbol is not mapped to any IR value" compile time errors.
This patch fixes the issue by adding the variables to the list of "captured" global variables from the host program, so that they are instantiated as part of the
internalProcedureBindingsin the bridge.The rational of doing it that way instead of changing
getScopeVariableListis thatgetScopeVariableListwould have to import all the module variables used inside the host since it cannot know which ones are referenced inside the internal procedure from the semantics::Scope information. The fix in this patch only instantiates the module variables from the host that are actually referenced inside the internal procedure.