Erik Faye-Lund kusmab...@gmail.com writes:
Why is this tagged as i965/fs, when everything seems to happen in the
glsl-optimizer?
On Thu, Oct 24, 2013 at 5:53 PM, Eric Anholt e...@anholt.net wrote:
I noticed this in a shader in Unigine Heaven that was spilling. While it
doesn't really
I noticed this in a shader in Unigine Heaven that was spilling. While it
doesn't really reduce register pressure, it shaves a few instructions
anyway (7955 - 7882).
---
src/glsl/opt_algebraic.cpp | 8
1 file changed, 8 insertions(+)
diff --git a/src/glsl/opt_algebraic.cpp
On Thu, Oct 24, 2013 at 8:53 AM, Eric Anholt e...@anholt.net wrote:
I noticed this in a shader in Unigine Heaven that was spilling. While it
doesn't really reduce register pressure, it shaves a few instructions
anyway (7955 - 7882).
---
src/glsl/opt_algebraic.cpp | 8
1 file
Why is this tagged as i965/fs, when everything seems to happen in the
glsl-optimizer?
On Thu, Oct 24, 2013 at 5:53 PM, Eric Anholt e...@anholt.net wrote:
I noticed this in a shader in Unigine Heaven that was spilling. While it
doesn't really reduce register pressure, it shaves a few
On Thu, Oct 24, 2013 at 11:12 AM, Erik Faye-Lund kusmab...@gmail.com wrote:
But wait a minute. x shifted by 0 is x, so the latter part looks
correct. But the first conditional seems to assume that 0 sifted by x
is x, but it's really 0, no? Shouldn't both cases return
ir-operands[0]? What am I
