[Bug 89508] Bad int(floatBitsToInt(vec4))

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=89508

--- Comment #10 from Iago Toral <itoral at igalia.com> ---
Ok, I think I know what is happening. The problem is that in case that fails we
generate IR like this:


(assign  (xyzw) (array_ref (var_ref temps) (constant int (1)) )
   (expression vec4 +
      (array_ref (var_ref temps) (constant int (1)) )
      (array_ref (var_ref temps) (swiz x (expression ivec4 bitcast_f2i (swiz
xxxx (array_ref (var_ref temps) (constant int (2)) ) )) )) ) ) 

The second operand to '+' has a variable indexing into temps (so it will use a
reladdr access), but then the register holding the reladdr is also an access
into the same array (so it will also need a scratch load).

The code in move_grf_array_access_to_scratch() does not handle this scenario.

The reason why the other case passes is because it splits the bitcast and
assigns it to a temporary like this:

(declare (temporary ) int floatBitsToInt_retval)
(assign  (x) (var_ref floatBitsToInt_retval)
   (expression int bitcast_f2i (swiz x (array_ref (var_ref temps) (constant int
(2)) ) )) ) 
(assign  (xyzw) (array_ref (var_ref temps) (constant int (1)) ) 
   (expression vec4 +
      (array_ref (var_ref temps) (constant int (1)) ) (array_ref (var_ref
temps) 
      (var_ref floatBitsToInt_retval) ) ) )

This way we resolve the reladdr to a temp variable (so the register holding the
reladdr value is no longer an array access that needs a scratch read), so we do
not hit the unsupported scenario.

I'll see if I can fix this.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/intel-3d-bugs/attachments/20150313/d2a18642/attachment.html>