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

Sean Silva
Sun, 07 Dec 2014 21:50:43 -0000

On Fri, Dec 5, 2014 at 8:02 AM, Robert Lougher <rob.lougher at gmail.com>
wrote:

> On 5 December 2014 at 06:49, Sean Silva <chisophugis at gmail.com>
wrote:
> >
> >
> > On Wed, Dec 3, 2014 at 4:23 AM, Robert Lougher <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).
> >
> >
> > Please provide examples of such "hand-optimised, and
highly-efficient"
> > routines and test cases (and execution conditions) that demonstrate a
> > performance improvement.
> >
>
> This sounds like a cop-out, but we can't share customer code (even if
> we could get a small runnable example).


I doubt a reduced and sanitized example would violate any policy. If even a
reduced and sanitized example violates your policy, then you may want to
start an internal discussion regarding this policy because it is difficult
to collaborate with such a policy. (it's not like you're being asked to
post a reduced example of a trade-secret algorithm; it's just a memcpy
loop).


>   But this is all getting
> beside the point.  I discussed performance issues to try and justify
> why the user should have control.  That was probably a mistake as it
> has subverted the conversation.  The blunt fact is that game
> developers don't like their loops being replaced and they want user
> control.


I'm not convinced. If the compiler produced code that was faster than what
they wrote, they would not be complaining.

-- Sean Silva


>   The real conversation I wanted was what form should this
> user control take.  To be honest, I am surprised at the level of
> resistance to giving users *any* control over their codegen.
> _______________________________________________
> 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/20141207/6767b4c5/attachment.html>