[LLVMdev] Memset/memcpy: user control of loop-idiom recognizer

[Philip Reames]

On 12/02/2014 11:45 AM, Reid Kleckner wrote:
> What if we had a pragma or attribute that lowered down to metadata 
> indicating that the variable length trip count was small?
>
> Then backends could choose to lower short memcpys to an inlined, 
> slightly widened loop. For example, 'rep movsq' on x86_64.
>
> That seems nice from the compiler perspective, since it preserves the 
> canonical form and we get the same kind of information from profiling. 
> Then again, I can imagine most game dev users just want control and 
> don't want to change their code.
I like this general idea.  Here's another possibility...

We actually already have such a construct in the form of the expect 
builtins. 
http://llvm.org/docs/BranchWeightMetadata.html#built-in-expect-instructions

One way to structure this would be:
if (__builtin_expect(N < SmallSize, 1)) {
   //small loop here
} else {
   // memcpy here
   // or unreachable if you're really brave
}

I could see us failing to exploit this of course.  :)


>
> On Tue, Dec 2, 2014 at 11:23 AM, Robert Lougher <rob.lougher at gmail.com 
> <mailto:rob.lougher at gmail.com>> wrote:
>
>     Hi,
>
>     In feedback from game studios a common issue is the replacement of
>     loops with calls to memcpy/memset.  These loops are often
>     hand-optimised, and highly-efficient and the developers strongly want
>     a way to control the compiler (i.e. leave my loop alone).
>
>     The culprit is of course the loop-idiom recognizer.  This replaces any
>     loop that looks like a memset/memcpy with calls.  This affects loops
>     with both a variable and a constant trip-count.  The question is, does
>     this make sense in all cases?  Also, should the compiler provide a way
>     to turn it off for certain types of loop, or on a loop individually?
>     The standard answer is to use -fno-builtin but this does not provide
>     fine-grain control (e.g. we may want the loop-idiom to recognise
>     constant loops but not variable loops).
>
>     As an example, it could be argued that replacing constant loops always
>     makes sense.  Here the compiler knows how big the memset/memcpy is and
>     can make an accurate decision.  For small values the memcpy/memset
>     will be expanded inline, while larger values will remain a call, but
>     due to the size the overhead will be negligible.
>
>     On the other hand, the compiler knows very little about variable loops
>     (the loop could be used primarily for copying 10 bytes or 10 Mbytes,
>     the compiler doesn't know).  The compiler will replace it with a call,
>     but as it is variable it will not be expanded inline.  In this case
>     small values may see significant overhead in comparison to the
>     original loop.  The game studio examples all fall into this category.
>
>     The loop-idiom recognizer also has no notion of "quality" - it always
>     assumes that replacing the loop makes sense.  While it might be the
>     case for a naive byte-copy, some of the examples we've seen have been
>     carefully tuned.
>
>     So, to summarise, we feel that there's sufficient justification to add
>     some sort of user-control.  However, we do not want to suggest a
>     solution, but prefer to start a discussion, and obtain opinions.  So
>     to start, how do people feel about:
>
>     - A switch to disable loop-idiom recognizer completely?
>
>     - A switch to disable loop-idiom recognizer for loops with
>     variable trip count?
>
>     - A switch to disable loop-idiom recognizer for loops with constant
>     trip count (can't see this being much use)?
>
>     - Per-function control of loop-idiom recognizer (which must work
>     with LTO)?
>
>     Thanks for any feedback!
>     Rob.
>
>     --
>     Robert Lougher
>     SN Systems - Sony Computer Entertainment Group
>     _______________________________________________
>     LLVM Developers mailing list
>     LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu>
>     http://llvm.cs.uiuc.edu
>     http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141202/5202408c/attachment.html>