[flang-commits] [flang] [llvm] [flang][flang-rt] Add support for non-standard TIMEF intrinsic (PR #185377)

via flang-commits flang-commits at lists.llvm.org
Mon Mar 16 02:10:49 PDT 2026


NimishMishra wrote:

> If existing compilers don't implement a language extension identically, we need to question whether it serves the needs of portability to add it to flang-new. Right now, people can't run a code with `TIMEF` at all, and need to resort to portable (and maybe standard) substitutes. If you implement a `TIMEF` that works like Intel, it makes any codes that expect nvfortran/XLF behavior work differently, which is usually worse than not working at all since it requires debugging. Same story if you implement it with the thread-local millisecond behavior -- it will lead to debugging and bug reports from Intel users. So please think carefully about whether or not you want to do this at all -- the differing behaviors mean that the first paragraph in our policy towards extensions doesn't apply to this one.

Thanks @klausler, this makes sense. I checked that even https://github.com/flang-compiler/flang/blob/master/runtime/flang/timef3f.c has this intrinsic. Do you think either of the following two to be doable:

1) We base LLVM Flang's implementation on Classic Flang, and document the same

2) We add some mechanism to control the granularity of measurements from TIMEF

_>> the differing behaviors mean that the first paragraph in our policy towards extensions doesn't apply to this one._

Understood, thanks for pointing this out. Would there be a way, in your understanding, to resolve this? Some downstream applications use this intrinsic and are currently hitting CEs due to lack of support in LLVM Flang, so we would be interested in some way to resolve this, without of course violating the policy towards extensions. 

https://github.com/llvm/llvm-project/pull/185377


More information about the flang-commits mailing list