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

Sean Silva chisophugis at gmail.com
Sun Dec 7 13:31:22 PST 2014


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

> On 5 December 2014 at 17:09, David Chisnall <David.Chisnall at cl.cam.ac.uk>
> wrote:
> > On 5 Dec 2014, at 16:02, Robert Lougher <rob.lougher at gmail.com> wrote:
> >
> >> The blunt fact is that game
> >> developers don't like their loops being replaced and they want user
> >> control.  The real conversation I wanted was what form should this
> >> user control take.
> >
> > This doesn't really make sense.  They're writing code in a
> high(ish)-level language and passing it to a compiler.  The processor
> doesn't understand C, so the compiler *must* replace it with something.
> Whether that's a call to a library routine, a scalar loop, a vector loop,
> or a completely unrolled sequence depends on heuristics in the compiler.
> >
>
> Yes, but why isn't the user allowed any control over what the compiler
> does?
>

Every bit of "control over what the compiler does" introduces extra
complexity to the interface between the compiler and the user. It is
essential for the maintainability of the compiler that the interface be
kept as small as possible. The "hold the mayo" analogy is misleading
because in the analogy the complexity of the user-"compiler" interface and
the needs of maintainability of the compiler are neglected (or rather
absorbed into the complexity of human-human interaction).

-- Sean Silva


>
> > If they want full control of the machine instructions that are
> generated, then there is a mechanism for doing this: inline assembly.
> >
>
> Of course they could do this, but this is like having to make your
> deli sandwich yourself instead of telling the guy to "hold the mayo".
>
> Rob.
>
> > The complaint can't be that it's not generating the same code, it is
> that the compiler is generating something with performance characteristics
> that are difficult to reason about from the input code.  That's always a
> danger when you use an optimising compiler, but it looks like this case is
> a pretty extreme example.
> >
> > David
> >
>
> _______________________________________________
> 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/d7bbeed4/attachment.html>


More information about the llvm-dev mailing list