[LLVMdev] "Anti" scheduling with OoO cores?

James Molloy james at jamesmolloy.co.uk
Sun Nov 2 05:02:12 PST 2014


... now with added sample!

On 2 November 2014 12:46, James Molloy <james at jamesmolloy.co.uk> wrote:

> Hi Andy, Dave,
>
> I've been doing a bit of experimentation trying to understand the
> schedmodel a bit better and improving modelling of FDIV (on Cortex-A57).
>
> FDIV is not pipelined, and blocks other FDIV operations (FDIVDrr and
> FDIVSrr). This seems to be already semi-modelled, with a
> "ResourceCycles=[18]" line in the SchedWriteRes for this instruction. This
> doesn't seem to work (a poor schedule is produced) so I changed it to also
> require another resource that I modelled as unbuffered (BufferSize=0), in
> the hope that this would "block" other FDIVs... no joy.
>
> Then I noticed that the MicroOpBufferSize is set to 128, which is wildly
> high as Cortex-A57 has separated smaller reorder buffers, not one larger
> reorder buffer.
>
> Even reducing it down to "2" made no effect, the divs were scheduled in a
> clump together. But "1" and "0" (denoting in-order) produced a nice
> schedule.
>
> I'd expect an OoO machine with a buffer of 2 ops would produce a very
> similar schedule as an in-order machine. So where am I going wrong?
>
> Sample attached - I'd expect the FDIVs to be equally spread across the
> MULs. (The extension to this I want to model is that we can have 2
> S-register FDIVs in parallel but only one D-reg FDIV, and never both, but
> that can wait until I've understood what's going on here!).
>
> Cheers,
>
> James
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141102/a947cb90/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test-scheduling.c
Type: text/x-csrc
Size: 563 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141102/a947cb90/attachment.c>


More information about the llvm-dev mailing list