[LICMPass] Runtime issues caused by LICMpass optimization

[XingYuShuai]

case:
test-code.txt
Commands：clang -O2 test-code.c && ./a.out 10 VS clang -O0 test-code.c && ./a.out 10
result：

[XingYuShuai]

IR informations obtained through '-opt-bisect-limit' option:
before run LICMpass:
184-test-code.txt
after run LICMpass:
185-test-code.txt

In this case , the store instruction shouledn't be removed.

[nikic]

Infinite loops without side effects are undefined behavior in C. Use -fno-finite-loops to make them well-defined.

[XingYuShuai]

Infinite loops without side effects are undefined behavior in C. Use -fno-finite-loops to make them well-defined.

after add option '-fno-finite-loops' ,the result is:

And if I changed the case to this:
test-code2.txt

commands changed to :clang -O2 test-code2.c && ./a.out 1 VS clang -O0 test-code2.c && ./a.out 1
the result is also different:

In this case , it dose not satisfy the infinit loops.

@nikic

[nikic]

Sorry, I didn't look carefully enough at your example. The issue is even more severe, because you are reading a non-atomic variable from a signal handler.

[XingYuShuai]

Sorry, I didn't look carefully enough at your example. The issue is even more severe, because you are reading a non-atomic variable from a signal handler.

Yes, so in LICM, promoteLoopAccessesToScalars function should consider the non-atomic variable readed from a signal handler.
And this issue should be open again?
I have a solution to address this issue.

[nikic]

@XingYuShuai No, your code is not well-defined. You can only read lock-free atomic or volatile sig_atomic_t from a signal handler.

[XingYuShuai]

@XingYuShuai No, your code is not well-defined. You can only read lock-free atomic or volatile sig_atomic_t from a signal handler.
Sorry, I don't fully understand lock-free atomic and volatile sig_atomic_t. But if the Run_Index is volatile or atomic , the StoreSafety in LICM.cpp would not be seted to StoreSafe.

[XingYuShuai]

@XingYuShuai No, your code is not well-defined. You can only read lock-free atomic or volatile sig_atomic_t from a signal handler.

@nikic If you mean the Run_Index is volatile or atomic, in these cases, there is no problem with open source version.
There are my test resultes:

test-code2-atomic.txt

test-code2-volatile.txt