STM: Inlining of tm_waiver functions

STM: Inlining of tm_waiver functions

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

int global;

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

__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

publicaciones de 6 / 0 nuevos
Último envío
Para obtener más información sobre las optimizaciones del compilador, consulte el aviso sobre la optimización.

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.

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

Thanks for pointing this out. Thisis a known issue. In our next whatif C++ STM compiler release,the tm_waiver/tm_pure will be inlined as we do today, but thecode 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;
}

Deje un comentario

Por favor inicie sesión para agregar un comentario. ¿No es socio? Únase ya