This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GCC/GLIBC and non-temporal instructions


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 <iant@google.com>
To: Sergey Oboguev <oboguev@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 <oboguev@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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]