60% of the time is spent in:
brw::fs_live_variables::compute_live_variables()

Interesting.

I cannot reproduce the slow down on commit 52901ec from August, so perhaps this isn't a problem with more recent versions than 10.1.3.

I do, however, see some improvements we could make to the generated code.

(In reply to Matt Turner from comment #2)
> I do, however, see some improvements we could make to the generated code.

Oh, even that problem has been fixed since the commit I tested.

Please test a newer version. If a newer version isn't available in your distro, you can build Mesa and then set LD_LIBRARY_PATH and LIBGL_DRIVERS_PATH to the lib/ directory in the Mesa build tree to run your application against it.

I also tested on latest git; the problem persists.

From callgrind_annotate:

324,681,210,134  ../src/mesa/mesa/src/mesa/drivers/dri/i965/brw_fs_live_variables.cpp:brw::fs_live_variables::compute_live_variables() [../src/mesa/mesa/lib/i965_dri.so]
 30,407,730,617  ../src/mesa/mesa/src/mesa/drivers/dri/i965/brw_fs_live_variables.cpp:brw::fs_live_variables::compute_start_end() [../src/mesa/mesa/lib/i965_dri.so]
 27,294,134,491  ../src/mesa/mesa/src/util/register_allocate.c:ra_add_node_adjacency [../src/mesa/mesa/lib/i965_dri.so]
 16,474,809,991  ../src/mesa/mesa/src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp:fs_visitor::assign_regs(bool) [../src/mesa/mesa/lib/i965_dri.so]

The compilation itself takes minutes, not the execution of the resulting shader.

52901ec
android: add CleanSpec.mk

Seems unrelated to compilaton times.

(In reply to Gonz from comment #5)
> 52901ec
> android: add CleanSpec.mk
> 
> Seems unrelated to compilaton times.

Yes... I wasn't claiming the commit fixed something. I was just saying that it was what I had installed.

Perhaps you can make a shader_test (see http://cgit.freedesktop.org/piglit/tree/tests/shaders/ssa/fs-if-def-else-break.shader_test?id=f18b947d7c03b81b989ed47551dc24bcc29cc0fc for example) that exhibits the problem?

I made one, but since it doesn't reproduce the problem I can't be sure of anything.

This one takes 13 seconds to compile. Change n to 70 or 80 and it gets worse.

[require]
GLSL >= 1.30

[fragment shader]
out vec4 fragColor;

const int n = 60;

vec4 a[n];
vec4 b[n];
vec4 c[4];

void init() {
    for(int i = 0; i < n; ++i) {
        a[i] = vec4(0.1, 0, 0, 0);
        b[i] = vec4(0.1, 0, 0, 0);
    }
}

void prod(in vec4 a[n], in vec4 b[n], out vec4 result[4]) {
	result[0] = vec4(0);
    for(int i = 0; i < n; ++i) {
        result[0] += a[i] * b[i];
    }
}

void main()
{
	init();
	prod(a, b, c);
    fragColor = c[0];
}

[test]

draw rect -1 -1 2 2
probe all rgba 0.6 0.0 0.0 0.0

Yes, that shader (n = 60) cannot be register allocated (at least with our current scheduling and allocation code) and ends up generating nearly 3600 instructions.

I would understand slow execution of that shader. But compilation?
So arrays with 60 elements are a WONTFIX?

It's not a WONTFIX, but I think it'll take some work.

The shader has enough live variables that it causes spilling. Each time we spill, we recalculate liveness. We could probably fix up the existing liveness information and save a bunch of time. We'd still generate awful code, though much more quickly.

The frontend compiler, based on some questionable heuristics and the lack of indirect addressing support in the i965 backend, lowers the indirect array accesses to a series of if statements, to do a binary search. We'd do significantly better to support indirect addressing and skip this stuff entirely.

It's on our TODO list, we just haven't gotten there yet.

Thanks for clarifying.

(In reply to Gonz from comment #7)
> This one takes 13 seconds to compile. Change n to 70 or 80 and it gets worse.

Gonz, on my SKL GT2, your shader takes 3 seconds to compile with latest Mesa.  Do you see similar improvement?

(In reply to Eero Tamminen from comment #12)
> (In reply to Gonz from comment #7)
> > This one takes 13 seconds to compile. Change n to 70 or 80 and it gets worse.
> 
> Gonz, on my SKL GT2, your shader takes 3 seconds to compile with latest
> Mesa.  Do you see similar improvement?

And now shader cache is now enabled, so it should take that time only on first startup.

Over the years, various changes on compiler have resulted in better compilation times. The shader test in comment #7 takes some seconds now with HSW, resolving this as fixed.