Well, it would help if someone who knows what this code does (and does not), ideally its authors, could clarify definitively.
Also, what happens if application performs inter-thread communication inside the loop? - Sergey ----- Original Message ---- From: Ian Lance Taylor <i...@google.com> To: Sergey Oboguev <obog...@yahoo.com> Cc: gcc@gcc.gnu.org Sent: Tue, January 3, 2012 12:08:22 PM Subject: Re: GCC/GLIBC and non-temporal instructions Sergey Oboguev <obog...@yahoo.com> writes: > Well, all these > > storent > emit_storent_insn > may_use_storent_in_loop > storent_optab > nontemporal > assign_set_nontemporal_move > mark_nontemporal_store > mark_nontemporal_stores > nontemporal_store_p > schedule_prefetches > should_issue_prefetch > issue_prefetch_ref > etc. > > things in GCC sources -- do they ever get triggered or not? Ah, you're quite right, I was not aware of that. The rule there appears to be the compiler will issue an mfence if it decides to use any non-temporal moves in a loop. However, I don't see anything in the code which will avoid using non-temporal moves, or a fence, if there are existing non-temporal moves (via instrinsic functions) in the loop. This seems like it is at least a documentation bug. > Also, looking up in GLIBC sources I can see MOVNTxxx instructions terminated > with SFENCE, but not prefixed with LFENCE. What could this possibly mean? You would have to ask the glibc maintainers about that. I don't know enough to speculate. Ian
