[feature][flang2] Initial support for opaque pointers

[xinliu-hnc]

This PR is based on PR #1306 submitted by @pawosm-arm, we have reviewed PR #1306 and made some changes on the original patch.

For typed pointers generated by functions, we modify the function in ll_structrue.cpp to uniformly use 'ptr' as the IR output string.
For some hard-coded typed pointers, we rewrite them with 'ptr', and remove some redundant cast_ops between pointers.
We also modify some test cases that use typed pointer IR.

In addition, this branch needs to be built with LLVM 15.

[pawosm-arm]

It looks OK. The changes here overlap with #1322. What will be the policy of merging those?

[bryanpkc]

@pawosm-arm #1321 and #1322 are stacked PRs, similar to stacked reviews on Phabricator. We can rebase #1322 once #1321 is merged, but they can be reviewed in parallel, although for #1322 you will have to select the top commit in order to isolate the changes.

Also, we must decide at the call tomorrow whether we should create a new opaque-pointer master branch for LLVM 15 and newer. Below are some pros and cons I can think of.

One master branch that handles both legacy IR and opaque pointer IR

• Pro: No need to maintain two branches at the same time. IR tests can be fitted with extra RUN lines and CHECK prefixes to verify the output in both modes.
• Pro: Flexibility in pairing Classic Flang binaries with different versions of LLVM. Is this actually used? Perhaps for debugging?
• Pro: If opaque pointer support requires some additional work before it can be used in production, we will have a usable master branch during that time.
• Con: Need to insert many conditional checks in the code generation phase, making the code less readable until we can rip out the deprecated code, depending on how much longer Classic Flang needs to keep working with LLVM 14 and older.

Two branches

• Pro: Cleaner code. IR tests in the new branch will only expect opaque pointer IR.
• Pro: The original master branch is completely unaffected for production use.
• Con: Need separate binaries for different versions of LLVM.
• Con: Need to maintain two branches at the same time, depending on how much longer Classic Flang needs to keep working with LLVM 14 and older.

[pawosm-arm]

@pawosm-arm #1321 and #1322 are stacked PRs, similar to stacked reviews on Phabricator. We can rebase #1322 once #1321 is merged, but they can be reviewed in parallel, although for #1322 you will have to select the top commit in order to isolate the changes.

Also, we must decide at the call tomorrow whether we should create a new opaque-pointer master branch for LLVM 15 and newer. Below are some pros and cons I can think of.

• Con: Need separate binaries for different versions of LLVM.

From the CI point of view, how big this problem is?

[bryanpkc]

From the CI point of view, how big this problem is?

Not a big problem at all. Let's assume that we create a branch named legacy which corresponds to the tip of master today. One commit will be needed on the master branch to remove the Classic Flang builds with release_14x and older classic-flang-llvm-project branches. The legacy branch requires no changes. In the classic-flang-llvm-project repo, one commit per legacy branch (release_14x, release_13x, etc.) is needed to change the Classic Flang branch they build and test with (from master to legacy).

[pawosm-arm]

For me clearer code outweighs any infrastructural considerations.

[PeixinQiao]

Should one option -no-opaque-pointer be added like clang?

[bryanpkc]

@PeixinQiao We have already decided at the biweekly technical call to not have an option to toggle the feature. If you don't want opaque pointers, use the legacy branch. The master branch will only work for LLVM 15 and above from now on. The CI workflows have already been updated to reflect this.

[bryanpkc]

@xinliu-hnc Could you rebase this on the master branch?

[PeixinQiao]

@PeixinQiao We have already decided at the biweekly technical call to not have an option to toggle the feature. If you don't want opaque pointers, use the legacy branch. The master branch will only work for LLVM 15 and above from now on. The CI workflows have already been updated to reflect this.

OK. Thanks for the info.

[xinliu-hnc]

@xinliu-hnc Could you rebase this on the master branch?

The branch is rebased.

[bryanpkc]

LGTM