On Monday, January 19, 2015 11:06:44 AM Eero Tamminen wrote: > 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.
That's true, having the compiler print statistics would be sensible. > 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. Yeah, I'd definitely like to add statistics along these lines. > [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. While that sounds like a good idea in theory, I've never seen it actually be a problem in practice. I suspect it will be difficult to find a non-contrived case that benefits sufficiently to justify the complexity. --Ken
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
