Hi,
On 01/16/2015 11:43 PM, Kenneth Graunke wrote:
On Thursday, January 15, 2015 07:12:20 AM Jason Ekstrand wrote:
On Jan 15, 2015 12:27 AM, "Eero Tamminen" <eero.t.tammi...@intel.com> wrote:
...
Any ideas how the loop unrolling could be reliably be taken into account
automatically in these statistics?
Maybe with some extra output from compiler which outputs loop counter and
marks loop start and end so that statistics generator can:
- count number of loops that could / could not be be unrolled
- multiply number of instructions inside loops by loop counter,
if the counter is a static value
- Eero
It already dumps out the number of loops in the final code. It would be
easy to add some code to the results parser to identify that number
changing.
Abdiel actually did that a while back - there's code on the "loops" branch
of the public shader-db. We never came up with a decent way to classify
loop changes as "helped" or "hurt".
Figuring out the number of loop invocations sounds like a good idea, but
is generally hard. I suppose we could at least find the common
for (i = 0; i < n; i++) pattern...pretty easy to recognize that at least.
Because it's possible that different loops get and don't get unrolled,
compiler could index loops and outputting at end list of indexes for
loops that couldn't be unrolled. Statistics code can then compare those
lists for differences.
If some of the earlier unrolled loops doesn't anymore get unrolled,
manual inspection is needed. If only additional unrolling happens,
I guess we can for now assume it to be better [1]. If exactly same
loops are unrolled, then comparing instruction counts is OKish.
However, there should be statistics also about memory fetches
(for textures, spilled registers etc). Depending on case, those
(and their scheduling) can often be more important than just
ALU operations.
[1] Next problem comes when backend gets logic for rejecting loop
unrolling based on I-cache utilization etc. Information about those
decisions need then to be included to the output & statistics too.
- Eero
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
