[flang-commits] [PATCH] D153916: [flang][NFC] Add F2023X documentation

Kiran Chandramohan via Phabricator via flang-commits flang-commits at lists.llvm.org
Thu Jun 29 05:25:42 PDT 2023


kiranchandramohan added a comment.

In D153916#4456315 <https://reviews.llvm.org/D153916#4456315>, @klausler wrote:

> In D153916#4454929 <https://reviews.llvm.org/D153916#4454929>, @kiranchandramohan wrote:
>
>> Thanks for putting up this document. Very informative and likely good feedback for standards committee members. I see that Brad has already commented, may be Mark and Gary also might be interested.
>>
>> A comment on the source line changes, relaxation for BOZ constants, using rank-one arrays to specify the rank and bounds of arrays might be useful.
>
> F18 <https://reviews.llvm.org/F18> has always had no limit on free from source line length; are there other source line changes that I missed?
>
> The BOZ literal changes originated in other implementations and they should already work in f18.  Some compilers allow BOZ as output statement I/O data items, and that is intentionally not supported.

For both these (line-length and BOZ) I was thinking a statement like the above will be good for conveying the status of these features.

There is probably a requirement to provide warnings or errors if these limits are breached for source line length.
6.3.2.1 A line shall contain at most ten thousand characters.
6.3.2.6 A statement shall not have more than one million characters.

> I did miss the thing about using vectors for bounds in array declarations; will read up on that and add it.  Thanks for the tip!





================
Comment at: flang/docs/F202X.md:140
+
+#### `SIMPLE` procedures
+
----------------
klausler wrote:
> kiranchandramohan wrote:
> > There might be some performance benefits if lowering can use llvm attributes like `argmem`/`argmemonly` for simple functions.
> > https://github.com/llvm/llvm-project/blob/main/llvm/docs/Frontend/PerformanceTips.rst#modeling-memory-effects
> My understanding is that calls to `PURE` procedures could use `memory(read, argmem:readwrite, inaccessiblemem:readwrite)` and `SIMPLE` could drop the `read`.  Is that also what you have in mind?
> 
> Calls to `SIMPLE` procedures from `DO CONCURRENT` are also safe from the bug that feature has with `PURE` procedures.
Yes, I am hoping that the argument-only memory access might help enable more optimisation since it does not access any global memory.

We have seen in the past a case where there are two usages of the same pure function with the same arguments and it required classic-flang to provide the memory attributes to do a CSE.

`bose_f` in the following example.
https://github.com/yambo-code/yambo/blob/931e54cd54d721ca5cbbe8df3cfae4b6e2f1ffc8/src/qp/QP_ppa_cohsex.F#L622


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D153916/new/

https://reviews.llvm.org/D153916



More information about the flang-commits mailing list