This is an archive of the discontinued LLVM Phabricator instance.

[RFC] Flang - generation of LLVM IR function attributes
Needs ReviewPublic

Authored by domada on Apr 28 2023, 7:52 AM.

Details

Summary

This patch proposes the way how LLVM IR function attributes should be generated for Fortran code.

  1. Expected output:

Flang should be able to attach LLVM IR function attributes as Clang does:

; Clang *.ll file:
define dso_local i32 @foo() #0 {
; some code
}
attributes #0 = { list of attributes for example: nounwind, target-cpu="cpu_name", etc}
  1. Passing MLIR attributes to LLVM IR for Fortran functions:

Flang can attach LLVM IR function attributes to passthrough MLIR attribute. passthrough attribute is lowered to LLVM IR by MLIR (see patch: https://reviews.llvm.org/D77072 ). The attributes which are dependent on the frontend options (like target-cpu, target-features etc.) should be passed directly to lower functions as it is done in this patch. Attributes which are dependent on the content of Fortran function (for example: alwaysinline) should be added to MLIR code during lowering from PFT to MLIR phase.

  1. Handling LLVM IR attributes for OpenMP related LLVM IR

OpenMP MLIR operations are lowered to LLVM IR by OpenMPIRBuilder. That's why OpenMPIRbuilder should be responsible for attaching LLVM IR attributes. The attributes which are dependent on frontend options (like target-cpu) should be passed to MLIR code as it is done here: https://reviews.llvm.org/D146612. Proposition of lowering these attributes is put here: https://reviews.llvm.org/D147313 and it is dependent on the result of discussion for patch: https://reviews.llvm.org/D147344 . OpenMP functions attributes which are not dependent on the frontend options should be added during LLVM IR generation like it is done for nounwind attribute: https://reviews.llvm.org/D147321

Diff Detail

Event Timeline

domada created this revision.Apr 28 2023, 7:52 AM
Herald added projects: Restricted Project, Restricted Project. · View Herald Transcript
domada requested review of this revision.Apr 28 2023, 7:52 AM
schweitz added inline comments.
flang/test/Lower/passthrough_attributes.f90
14

Is there a reason each distinct function in the compilation unit has its own target attribute? (The target attribute is attached to the module, no?)

+@ftynse and @mehdi_amini
I believe Alex or Mehdi said before that the passthrough support was just a temporary solution and we must not rely on it in more places.

domada added inline comments.Apr 28 2023, 9:02 AM
flang/test/Lower/passthrough_attributes.f90
14

Clang allows to generate different target for every function via __attribute macro:

__attribute__((target("arch=atom")))
void foo() {} // will be called on 'atom' processors.
__attribute__((target("default")))
void foo() {} // will b

That's why Clang generates different target info for every function. I think we should follow this way for Fortran.

clementval added inline comments.
flang/test/Lower/passthrough_attributes.f90
14

I might be wrong but the __attribute__ macro is not something we have support in the frontend/fortran. What's the plan here?

domada added inline comments.Apr 28 2023, 9:37 AM
flang/test/Lower/passthrough_attributes.f90
14

Currently I am not planning to add support for __attribute__ macro in frontend.

IMO we should enable support for __attribute___ in MLIR code even if we currently have no support for __attribute__ macro in the frontend.

tschuett added a subscriber: tschuett.EditedApr 29 2023, 9:26 AM

They are attributes. They are not macros. Clang Sema analyses them and reports misbehaviour. IDK, whether Fortran supports attributes, but you can mark functions as hot and cold or assign them different cpus, which can be useful.

GFortran seems to support attributes.

domada edited the summary of this revision. (Show Details)May 4 2023, 5:03 AM
ftynse added a comment.May 8 2023, 4:34 AM

+@ftynse and @mehdi_amini
I believe Alex or Mehdi said before that the passthrough support was just a temporary solution and we must not rely on it in more places.

Indeed. "Passthrough" must not be used unless for quick prototyping to check which attributes are needed before modeling them as properly defined first-class attributes in MLIR. There is no verification, it has strings everywhere. I'll update the documentation to better reflect this.

domada added a comment.May 9 2023, 2:21 AM

+@ftynse and @mehdi_amini
I believe Alex or Mehdi said before that the passthrough support was just a temporary solution and we must not rely on it in more places.

Indeed. "Passthrough" must not be used unless for quick prototyping to check which attributes are needed before modeling them as properly defined first-class attributes in MLIR. There is no verification, it has strings everywhere. I'll update the documentation to better reflect this.

Hi Alex,
Thank you for your feedback. I would like to ask if there are any plans to add LLVM-IR attributes (noinline, nounwind, etc.) to LLVM dialect?

ftynse added a comment.May 9 2023, 3:13 AM

Thank you for your feedback. I would like to ask if there are any plans to add LLVM-IR attributes (noinline, nounwind, etc.) to LLVM dialect?

I don't have such plans. But I am happy to review design / patches if somebody has got time to implement these.

Matt added a subscriber: Matt.May 17 2023, 10:27 AM