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

[via flang-commits]

================
@@ -413,6 +413,18 @@ double RTNAME(Dsecnds)(double *refTime, const char *sourceFile, int line) {
 // GNU extension function TIME()
 std::int64_t RTNAME(time)() { return time(nullptr); }
 
+// Intel extension function TIMEF()
+// Returns number of seconds that have elapsed since the first time
+// TIMEF was called. For the first call, it returns 0.
+double RTNAME(Timef)() {
+  static double first = -1;
----------------
NimishMishra wrote:

> Note: as I understand it, thread-local would keep a separate value for each thread, whereas mutex would have one value shared between all threads. Thus, behavior would be very different.

@eugeneepshteyn : Yes you are right, sorry for mixing the terminology. I tested the following program with ifort 2021.11.0:

```
use IFPORT
real results(10)
integer i

results = 0.0
!$omp parallel do
do i=1, size(results)
  call sleep(i)
  results(i) = timef()
end do
!$omp end parallel do

print *, results
end
```

And got the following output:

```
0.0000000E+00   2.000000       5.000000       9.000000       14.00000    
   5.000000       12.00000       20.00000       29.00000       39.00000    
```

By documentation from Intel, the first call to TIMEF returns a 0. My understanding is that if the variable were private to each thread, that we should have observed 0.0000000E+00 for all outputs. But since we observe non-zero outputs, that can only happen if one thread inits the TIMEF shared variable, and the other threads access it as per their execution.

The access to the TIMEF shared variable would be through mutex.

Again, sorry for the mixup, I was meaning to say that access to TIMEF variable behaves like a critical section, matching what @kkwli mentioned about XLF.

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