| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
When analyzing a loop where the loop condition is expressed in the
non-standard order (e.g. "4 > i" instead of "i < 4"), we were
reversing the condition incorrectly, leading to a loop bound that was
off by 1.
Fixes piglit tests {vs,fs}-loop-bounds-unrolled.shader_test.
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
| | |
|
| | |
|
| |
|
|
| |
Fixes loop-07.frag.
|
| |
|
|
|
|
| |
Fix the following GCC warning.
loop_controls.cpp: In function 'int calculate_iterations(ir_rvalue*, ir_rvalue*, ir_rvalue*, ir_expression_operation)':
loop_controls.cpp:88: warning: format not a string literal and no format arguments
|
| |
|
|
|
|
| |
The loop_controls pass didn't look at the counter values it put in ir_loop
on previous iterations, so while the first iteration worked, subsequent
ones couldn't determine max_iterations.
|
| |
|
|
|
|
|
|
|
|
|
| |
The places where constant_expression_value are still used in loop
analysis are places where a new expression tree is created and
constant folding won't have happened. This is used, for example, when
we try to determine the maximal loop iteration count.
Based on review comments by Eric. "...rely on constant folding to
have done its job, instead of going all through the subtree again when
it wasn't a constant."
|
| | |
|
| | |
|
| | |
|
|
|
This is the next step on the road to loop unrolling
|
