[llvm-dev] disable loop unrolling for store of large objects?

[Jameson Nash via llvm-dev]

The switch goes in the other direction: if you emit memcpy, LLVM will try
pick the best operation to represent it (works in most cases, although
sometimes early optimizations might get missed). If you emit load/store,
it'll unroll it (usually either in SROA or legalization, iirc).


On Mon, Oct 29, 2018 at 1:31 PM Bagel <bagel99 at gmail.com> wrote:

> Yes, I had noticed that if I generated memcpy, it did what I wanted.  I had
> hoped that there was a switch that would cause LLVM to convert a store to a
> memcpy if it was greater than a given size.
>
> Sigh.  Guess I'll have to do it in the front end.
>
> Thanks, brian
>
>
>
> On 10/29/18 12:27 PM, Jameson Nash wrote:
> > If you always generate a `memcpy` call (intrinsic) instead of load/store
> to
> > move values around, the resulting machine code will be as you want. (You
> might
> > add a heuristic that it only uses memcpy for values that are much larger
> than a
> > register, but LLVM does pretty well regardless)
> >
> > On Mon, Oct 29, 2018 at 1:08 PM Bagel via llvm-dev <
> llvm-dev at lists.llvm.org
> > <mailto:llvm-dev at lists.llvm.org>> wrote:
> >
> >     If a store has a type which is "large", the code generated is loop
> unrolled.
> >     For example:
> >
> >     %R = type {i32, [255 x i32]}
> >     @a = global %R zeroinitializer, align 4
> >     define void @foo(%R* %y$) nounwind {
> >     L.0:
> >             %y = alloca %R*
> >             store %R* %y$, %R** %y
> >             %0 = load %R*, %R** %y
> >             %1 = load %R, %R* %0
> >             store %R %1, %R* @a
> >             br label %return
> >     return:
> >             ret void
> >     }
> >
> >     generates a huge number of instructions.  Is there a flag somewhere
> (I couldn't
> >     find one) that which cause this store loop not to be unrolled.
> >
> >     Thanks, brian
> >     _______________________________________________
> >     LLVM Developers mailing list
> >     llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> >     http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181029/ed1b15a0/attachment.html>