hint-expression is an IntegerAttr, because it can be a combination of multiple values from the enum omp_sync_hint_t (Section 2.17.12 of OpenMP 5.0)
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Thanks @shraiysh for the fix.
Would it be possible to keep the new representation but custom print or parse the hint as strings (since strings are more readable)?
It can be done and it certainly would be more readable, but one catch is that the frontend has to first convert an integer into such strings, which we will then again convert to the integer. Plus we would lose the assemblyFormat. Basically, the lowering would be something like this
#pragma omp critical hint(10) // C/C++ or Fortran
omp.critical hint(speculative) hint(contended) // MLIR
__kmpc_omp_critical_with_hints(..., 10) // LLVM IR
Please let me know if I should change it to this.
The builder (which is an interface for a frontend) can take in a hint as an integer, the parser and printer only has to deal with conversions.
For the assembly format you need a custom part only for the hint.
The format can also be hint(a,b).
mlir/include/mlir/Dialect/OpenMP/OpenMPOps.td | ||
---|---|---|
380 | Having an extra unit attr just for the sake of pretty-printing sounds obnoxious. We can just skip printing the hint altogether if it has the default (0) value. The only thing it will require is to have custom<SynchronizationHint>($hint) also print (or not) the "hint" keyword. | |
mlir/lib/Dialect/OpenMP/IR/OpenMPDialect.cpp | ||
962 | Please document top-level functions. | |
978 | This will just ignore keywords that are not in this list, I would rather emit an error than silently discard input. | |
1064 | hint(none) works by accident because unknown keywords are ignored, hint(all_possible_hints) has exactly the same effect... |
mlir/lib/Dialect/OpenMP/IR/OpenMPDialect.cpp | ||
---|---|---|
1002 | Nit: /// here and below for top-level comments. |
Addressed comments. I do not have commit access, can someone please land this revision. Thank you.
Will you be cherry-picking this patch to fir-dev?
I am sorry for the delay, I missed this notification somehow, just saw it. I will cherry-pick this patch to fir-dev soon.
Having an extra unit attr just for the sake of pretty-printing sounds obnoxious. We can just skip printing the hint altogether if it has the default (0) value. The only thing it will require is to have custom<SynchronizationHint>($hint) also print (or not) the "hint" keyword.