Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: James Molloy <james <at> jamesmolloy.co.uk>
Subject: "Anti" scheduling with OoO cores?
Newsgroups: gmane.comp.compilers.llvm.devel
Date: Sunday 2nd November 2014 12:46:41 UTC (over 3 years ago)
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
 
CD: 13ms