On Fri, Aug 23, 2013 at 8:55 AM, Paul Berry <stereotype...@gmail.com> wrote: > On 22 August 2013 16:08, Matt Turner <matts...@gmail.com> wrote: >> >> --- >> src/glsl/builtins/ir/frexp.ir | 25 >> +++++++++++++++++++++++++ >> src/glsl/builtins/ir/ldexp.ir | 25 >> +++++++++++++++++++++++++ >> src/glsl/builtins/profiles/ARB_gpu_shader5.glsl | 10 ++++++++++ >> 3 files changed, 60 insertions(+) >> create mode 100644 src/glsl/builtins/ir/frexp.ir >> create mode 100644 src/glsl/builtins/ir/ldexp.ir >> >> diff --git a/src/glsl/builtins/ir/frexp.ir b/src/glsl/builtins/ir/frexp.ir >> new file mode 100644 >> index 0000000..a514994 >> --- /dev/null >> +++ b/src/glsl/builtins/ir/frexp.ir >> @@ -0,0 +1,25 @@ >> +((function frexp >> + (signature float >> + (parameters >> + (declare (in) float x) >> + (declare (out) int exp)) >> + ((return (expression float frexp (var_ref x) (var_ref exp))))) > > > Having an ir_expression that writes to one of its parameters is going to > break assumptions in a lot of our optimization passes.
I'm concerned that that may be a problem we have to solve anyway. While our hardware doesn't support an frexp instruction (like e.g., AMD does) and we could probably do what you suggest, we do have instructions that correspond directly to the uaddCarry() and usubBorrow() built-ins in this same extension. They return a value and also have an out parameter. genUType uaddCarry(genUType x, genUType y, out genUType carry); genUType usubBorrow(genUType x, genUType y, out genUType borrow); We could probably avoid the problem you describe by lowering them, but it's feeling increasingly distasteful. Your code would make a good piglit test. I'll do some experiments. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
