Addresses and properties (bounds, length parameters) of host
variables associated in an internal procedure were all passed via
an extra tuple argument of the internal procedure.
This extra tuple is in general an overhead: it must be created and
passed, and require creating thunks when taking the address of the
internal procedure.
This patch allows not using the tuple for host global variables
(from modules, common block, or local saved variables) since they can
be instantiated from the fir.global symbol in the internal procedure
instead.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Aside from the name of hasTupleAssociations(), all builds and tests correctly and looks good.
flang/include/flang/Lower/HostAssociations.h | ||
---|---|---|
35–37 | This doesn't seem right. hasTupleAssociations() returns true when there are no tuple symbols? Should this be called hasNoTupleAssociations()? |
flang/include/flang/Lower/HostAssociations.h | ||
---|---|---|
35–37 | Woops, of course, thanks ! I will actually keep the name and reverse the logic since its only use is negating it (so that I can remove the negation). |
Honor hasTupleAssociations name by reversing the logic inside and at its use point.
Update one piece of code in ArrayCopyValue that relied on the presence of a tuple
argument to detect internal procedures. Add an fir.internal_proc attribute to internal
function that are capturing host variables so that they can be easily detected even if
they do not have a tuple argument (I thought about using the mangling, but thought
an attribute would be stronger).
This doesn't seem right. hasTupleAssociations() returns true when there are no tuple symbols? Should this be called hasNoTupleAssociations()?