<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Sep 21, 2018, at 11:23 AM, Friedman, Eli via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">On 9/21/2018 12:15 AM, Jonas Paulsson wrote:<br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><br class="">If so, then yes, this is probably a case where the aggressive LoopPRE mentioned in the other thread that Eli linked to would be useful. Once we'd done the PRE, then everything else should collapse.<br class=""></blockquote>Thanks for the link, it's good to know this issue is recognized. If I understand it correctly, the reason clang is storing in each iteration is due to concurrency.<br class=""></blockquote><br class="">Yes, basically... IIRC LLVM did the wrong thing a long time ago, but we fixed it as part of implementing the C++11 atomics model.<br class=""><br class=""><blockquote type="cite" class="">As a newbie I wonder how this works in practice since even if the value is stored in each iteration two threads could still do this simultaneously if not some sort of atomic operation is doing it, right? What happens here is that the value of 'a' is loaded once before the loop, then incremented and stored in each iteration. How does that help with multiple threads compared to storing it after the loop?<br class=""></blockquote><br class="">The interesting case is the case where the store is dynamically dead (not executed in any iteration of the loop); we have to make sure we don't introduce a race in that case. As you note, if the store is executed in any iteration, and there isn't any synchronization inside the loop, we can ignore the possibility of a race.<br class=""></div></div></blockquote><div><br class=""></div><div>See:</div></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div><div><a href="https://www.di.ens.fr/~zappa/readings/pldi13.pdf" class="">https://www.di.ens.fr/~zappa/readings/pldi13.pdf</a></div></div><div><div><a href="https://www.di.ens.fr/~zappa/readings/c11comp.pdf" class="">https://www.di.ens.fr/~zappa/readings/c11comp.pdf</a></div></div></blockquote><div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><blockquote type="cite" class="">Is there an option to change this behavior in gcc or clang? It seems that gcc is assuming a single thread, while clang is not. It would be nice to have the same setting here when comparing them. Or am I missing something?<br class=""></blockquote><br class="">There is no option to control it; theoretically, we could add one, I guess, but it's a minor optimization in most cases, and most non-trivial programs are concurrent anyway.<br class=""><br class="">For your loop, the condition of the if statement is a comparison of a constant and an induction variable, so it's possible to prove the store is always executed. I assume gcc is proving that (either directly, or by performing some other transform which makes the condition trivial).<br class=""><br class="">-Eli<br class=""><br class="">-- <br class="">Employee of Qualcomm Innovation Center, Inc.<br class="">Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project<br class=""><br class="">_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a><br class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<br class=""></div></div></blockquote></div><br class=""></body></html>