Intel® Software Network

Hi -

When using the default compiler optimization, it seems that the compiler is inlining functions which are supposed to be tm_waiver. Consider the following simple piece of code.

#include <stdio.h>

int global;

__attribute__ ((tm_waiver)) void foo2() {
 printf("foo2_start\n");
 global++;
 printf("foo2_end\n");
}

__attribute__ ((tm_callable)) void foo1() {
 foo2();
}

main() {
 __tm_atomic {
   foo1();
 }
}

When invoking the compiler using default optimization it gives the following warning  messages:

% icc -Qtm_enabled test.c -o test
tx_warning: test.c(17): a non tm_callable/tm_waiver intrinsic function 'printf' called inside __tm_atomic section
tx_warning: test.c(17): a non tm_callable/tm_waiver intrinsic function 'printf' called inside __tm_atomic section
tx_warning: test.c(12): a non tm_callable/tm_waiver intrinsic function 'printf' called inside __tm_atomic section
tx_warning: test.c(12): a non tm_callable/tm_waiver intrinsic function 'printf' called inside __tm_atomic section

When invoking the compiler using optimization level 0 it gives no warning messages:
% icc -Qtm_enabled test.c -o test -O0


Ispecting the code produced using the default optimization reveals two things. First, that the calls to printf are inlined inside the transaction. This should be fine and the warning messages can be ignored. Second, the increment of the global variable is also inlined inside the transaction and calls to the STM for isolating the read/write are made. I wouldn't expect this to happen since the increment is inside a tm_waiver function for which the compiler is supposed not to create any transactional code.

Thanks,

-Haris

Yes, this looks like a compiler issue. However, when I test with our current development compiler the bug seems to have been fixed already.

Since we're already planning a new What-If release, (and we're about to start all of the processes needed to release the code externally), I think you're just going to have to wait for that release for the bug fix.(As Ravi said elsewhere we currently expect this to be released early next month)

Thanks for the report, though. It's useful to get feedback.

---

Jim Cownie
(Intel Performance, Analysis and Threading Lab)

OK. It's good to know that a new release is coming up

Thanks for pointing this out. This is a known issue. In our next whatif C++ STM compiler release, the tm_waiver/tm_pure will be inlined as we do today, but the code inside the inlined function will not be instrumented based on "tm_waiver" block concept.

Xinmin Tian (Intel)

 

It seems that this is also a problem with instrinsic functions such as memcpy. The compiler adds no instrumentation code  when it inlines intrinsic functions in the transactional code path.

Yes, this looks like a bug, assuming my example below is similar to the case you are discussing. Unfortunately we're past the code-freeze for the next What-If release, so it's unclear if this can be fixed for that release

Note, though, that this will only be a performance issue in the next release, since the presence of the non tm_safe function will force serialization (whereas in the current release it's a correctness issue since there such functions are implicitly treated as tm_waiver, so do not force serialization).

struct ls 
{
    int data[80];
};

extern struct ls * p;

int foo(void)
{
    __tm_atomic {
        struct ls local;
        
        *p = local;
    }

    return 1;
}

---

Jim Cownie
(Intel Performance, Analysis and Threading Lab)