[LLVMdev] Memset/memcpy: user control of loop-idiom recognizer
alexr at leftfield.org
Tue Dec 2 14:18:00 PST 2014
On Dec 3, 2014, at 6:12 AM, Eric Christopher <echristo at gmail.com> wrote:
>> On Tue Dec 02 2014 at 12:12:01 PM Robert Lougher <rob.lougher at gmail.com> wrote:
>> On 2 December 2014 at 19:57, Joerg Sonnenberger <joerg at britannica.bec.de> wrote:
>> > On Tue, Dec 02, 2014 at 07:23:01PM +0000, Robert Lougher wrote:
>> >> 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).
>> > I doubt that. If anything, it means the lowering of the intrinsic is
>> > bad, not that the transformation should not happen.
>> > Joerg
>> Yes, that's why I talked about variable and constant trip-counts. For
>> constant loops there generally isn't a problem, as they can be lowered
>> inline (if small). Variable loops, however, get expanded into a
>> library call.
> So the biggest problem is that you don't want a call and would prefer to have inline memcpy code everywhere or something else? If the memcpy isn't being lowered efficiently I'm curious as to what isn't being lowered well.
Our C library amplifies this problem by being in a dynamic library, so the call has additional overhead, which for small trip counts swamps the copy/set.
Certainly, the lowering can be better across the many cases as discussed elsewhere in this thread.
Game developers expect precise control and are surprised by this canonicalization. They also don't have the compiler's frame of reference as a basis for understanding issues like this.
>> > _______________________________________________
>> > LLVM Developers mailing list
>> > 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
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev