This is an archive of the discontinued LLVM Phabricator instance.

[flang] Establish a single source of target information for semantics
ClosedPublic

Authored by klausler on Jul 1 2022, 3:07 PM.

Details

Summary

Create a TargetCharacteristics class to centralize the few items of
target specific information that are relevant to semantics. Use the
new class for all target queries, including derived type component layout
modeling.

Future work will initialize this class with target information
provided or forwarded by the drivers, and use it to fold layout-dependent
intrinsic functions like TRANSFER().

Diff Detail

Event Timeline

klausler created this revision.Jul 1 2022, 3:07 PM
Herald added a project: Restricted Project. · View Herald Transcript
klausler requested review of this revision.Jul 1 2022, 3:07 PM

From a design point, I would have expected an abstract base class. Targets can implement it in any way they wish. Maybe the driver is better place for target-specific information. Then you can have a factory method with the target target triple.

There was a discussion that Flang should have used comdats:
https://reviews.llvm.org/D127455

From a design point, I would have expected an abstract base class. Targets can implement it in any way they wish. Maybe the driver is better place for target-specific information. Then you can have a factory method with the target target triple.

There was a discussion that Flang should have used comdats:
https://reviews.llvm.org/D127455

This patch collects into one place the few items of target information that are relevant to f18 semantics (not optimization or lowering!), which were scattered around various data structures or undefined, and puts them behind a sensible API that suffices for the needs of f18 semantics, which really just needs to know the available types and how to lay them out in derived types so that semantics can build the derived type information tables and fold some layout-dependent intrinsic functions. How that type information is acquired and installed is another concern not within the scope of this patch. The next step will be to use this API in semantics to guide the folding of the TRANSFER intrinsic function and see whether it is a good fit, adjusting it if it is not.

We always welcome new contributors to the LLVM Fortran effort; see flang/docs/GettingInvolved.md for more information. Thank you for your interest.

Targets can implement it in any way they wish

@tschuett, the plan is to avoid re-implementing target information in flang. We wish to plug into the existing target description in llvm (probably from using the infrastructure in llvm/include/llvm/Target). What this patch does is to centralize the target dependent info in semantics into one class that has an interface in terms of Fortran types (which is not the case of llvm generic infrastructure). The next steps that will probably have to be taken to be able to configure the target data are:

  • let the driver select the target triple (either command line or host), and get the LLVM representation for it (llvm::TargetMachine ? llvm::DataLayout ? ... ).
  • to let the driver use relevant information from this target to set up the TargetCharacteristics representation (whose ctor or member functions might have to be adapted to do that).
  • ensure the driver passes the triple to lowering (the comdat point might require using it when selecting linkage if windows LLVM target does not fulfill the target independent LLVM linkonce attribute description from the manual).

Anyone is more than welcome to launch an RFC to precisely define how this target dependent configuration should occur.

So you should see the TargetCharacteristics class as a generic wrapper to translate LLVM target info into something meaningful in terms of Fortran.

klausler updated this revision to Diff 442116.Jul 4 2022, 9:39 AM

Attempt to work around build problems on Windows.

The Clang community was discussing on Discourse to move to MLIR codegen. It ended with an invitation to a meeting. Maybe it is a win for you to cooperate on ugly stuff like, e.g., comdats.

The Clang community was discussing on Discourse to move to MLIR codegen. It ended with an invitation to a meeting. Maybe it is a win for you to cooperate on ugly stuff like, e.g., comdats.

I suppose you are mentioning this thread: https://discourse.llvm.org/t/rfc-an-mlir-based-clang-ir-cir/63319/73 ?

For the BIND(C) and runtime interface parts at least, having a C/C++ ABI for the target available in MLIR could be useful. If it brings COMDAT support in MLIR, that may be a good way to share read only data between compilation units for the targets that supports it (linkonce/linkonce_odr gets us there on linux, but without any possible sanity checks at linktime that the data is indeed equivalent, although my understanding is that ExactMatch COMDAT flag support is low (i.e: not supported in ELF)).

Exactly. Comdats were just one example. There are more challenges with ABIs, e.g., https://github.com/rust-lang/rust/issues/97463

klausler updated this revision to Diff 442375.Jul 5 2022, 12:44 PM

Another tweak to appease MSVC. Did you know that MSVC does not predefine x86_64?

klausler updated this revision to Diff 442392.Jul 5 2022, 1:53 PM
klausler edited the summary of this revision. (Show Details)

Defer tuning of enabled type kinds to the target for now, to try to get through the MSVC build.

ping now that MSVC build succeeds

This revision is now accepted and ready to land.Jul 6 2022, 8:40 AM