[llvm-dev] [RFC] Non-Temporal hints from Loop Vectorizer

Tue May 3 16:40:20 PDT 2016

> On May 3, 2016, at 1:36 PM, Stephen Canon via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> Expanding on my initial reaction:
> 
> x86 NT stores do have a valid use case, but it is limited, and a compiler absolutely should not be generating them without either (a) an explicit request from the programmer, or (b) a reasonably precise memory model that includes caches of an explicit targeted machine, because they are only beneficial if you can prove that the address being stored to is not in cache, and would not be present in cache at next use even if a normal store were used.
> 
> For very simple synthetic benchmarks with large loop trip counts (and by “large” I really mean “staggeringly huge”, given modern L3 sizes), it’s possible to statically know that these criteria are satisfied without a full cache model, but those cases are pretty limited and not obviously beneficial outside of benchmarks.
> 
> Weight against this small benefit, there are a two big things that can go wrong with NT stores, which make me very wary of auto-generating them:
> 
> - they break some of the usual ordering guarantees.
> - the performance is catastrophically bad (significantly worse than normal stores) when the address is present in cache.
> 
> My experience is that while there are indeed a few beneficial real-world uses of these instructions, if they aren’t deployed extremely carefully they cause more problems than they solve, and LLVM doesn’t at present have the infrastructure that would be needed to accurately inform their use.
That was my conclusion too.

I actually thought about autogenerating NT hints too, but before diving into implementing that I carried out some experiments on benchmarks like SPEC and similar - I tried to model what the compiler would do there and replaced usual stores in candidate loops with __builtin_nontemporal_store. I didn't see any gains at that moment (I don't remember if I saw losses though, but I can see that we can get them easily), so I dropped that.

Michael
> 
> – Steve
> 
>> On May 3, 2016, at 3:45 PM, via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>> 
>> Steve Canon is on vacation, so I’m going to word for word quote his take on the compiler autogenerating nontemporal hints:
>> 
>> "nope nope nope nope nope nope nope nope nope nope nope nope nope nope nope nope nope nope nope nope nope nope nope nope nope n” — Steve Canon
>> 
>> —escha
>> 
>>> On May 3, 2016, at 10:26 AM, via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>>> 
>>> Non-temporal hints are extremely dangerous to use in practice IMO; they hurt far more than they help in real programs. Compilers really should not be using them without the programmer’s knowledge, even if it helps some microbenchmark, because in real programs, the only one who really knows the memory access patterns is the programmer. Unless you can be certain the output of a function or loop is literally bigger than the entire cache and won’t be used again for a long time, forcibly evicting it from cache tends to be a very costly mistake.
>>> 
>>> —escha
>>> 
>>>> On May 3, 2016, at 3:40 AM, Hahnfeld, Jonas via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>>>> 
>>>> Hello all,
>>>> 
>>>> I've been wondering why Clang doesn't generate non-temporal stores when
>>>> compiling the STREAM benchmark [1] and therefore doesn't yield optimal
>>>> results.
>>>> 
>>>> It turned out that the Loop Vectorizer correctly vectorizes the arithmetic
>>>> operations and also merges the loads and stores into vector operations.
>>>> However it doesn't add the '!nontemporal' metadata which would be needed for
>>>> maximal bandwidth on X86.
>>>> I briefly looked into this and for non-temporal memory instructions to work,
>>>> the memory address would have to be aligned to the vector length which
>>>> currently isn't the case neither.
>>>> 
>>>> To summarize the following things would be needed to give non-temporal
>>>> hints:
>>>> 1) Ensure correct alignment of merged vector memory instructions
>>>> This could be implemented by executing the first (scalar) loop iterations
>>>> until the addresses for loads and stores are aligned, similar to what already
>>>> happens for the remainder of the loop. The larger alignment would also allow
>>>> aligned vector instructions instead of the currently unaligned ones.
>>>> 
>>>> 2) Give non-temporal hints when different array elements are only used once
>>>> per loop iteration
>>>> We probably need to analyze the different load and stores per loop iteration
>>>> for this...
>>>> 
>>>> Any thoughts or any ongoing work that I'm missing?
>>>> 
>>>> Thanks,
>>>> Jonas
>>>> 
>>>> 
>>>> [1] https://www.cs.virginia.edu/stream/
>>>> 
>>>> --
>>>> Jonas Hahnfeld, MATSE-Auszubildender
>>>> 
>>>> IT Center
>>>> Group: High Performance Computing
>>>> Division: Computational Science and Engineering
>>>> RWTH Aachen University
>>>> Seffenter Weg 23
>>>> D 52074  Aachen (Germany)
>>>> Hahnfeld at itc.rwth-aachen.de
>>>> www.itc.rwth-aachen.de
>>>> 
>>>> 
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> llvm-dev at lists.llvm.org
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>> 
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>> 
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev