1. 04 Apr, 2019 1 commit
    • Tapani Pälli's avatar
      nir: fix compiler warnings about implicit conversions · 061407ec
      Tapani Pälli authored
      
      
      Instead of implicitly converting UINT64_MAX to operation destination
      type, we explicitly set the correct max depending on type.
      
      So instead of generating:
      
         uint8_t dst = (src0 + src1) < src0 ? (UINT64_MAX) : (src0 + src1);
      
      we do:
      
         uint8_t dst = (src0 + src1) < src0 ? (UINT8_MAX) : (src0 + src1);
      
      This clears following warnings during compilation:
      
        warning: implicit conversion from 'unsigned long' to 'uint1_t'
        warning: implicit conversion from 'unsigned long' to 'uint8_t'
        warning: implicit conversion from 'unsigned long' to 'uint16_t'
        warning: implicit conversion from 'unsigned long' to 'uint32_t'
      Signed-off-by: Tapani Pälli's avatarTapani Pälli <tapani.palli@intel.com>
      061407ec
  2. 16 Dec, 2018 2 commits
  3. 13 Dec, 2018 1 commit
  4. 05 Dec, 2018 1 commit
  5. 24 Jul, 2018 1 commit
  6. 06 Jul, 2018 1 commit
  7. 12 Apr, 2018 1 commit
  8. 03 Mar, 2018 1 commit
  9. 30 Mar, 2017 3 commits
  10. 14 Mar, 2017 1 commit
  11. 10 Mar, 2017 1 commit
  12. 19 Dec, 2016 3 commits
  13. 26 May, 2016 1 commit
  14. 17 Mar, 2016 2 commits
  15. 26 Jan, 2016 1 commit
  16. 02 Dec, 2015 1 commit
  17. 23 Nov, 2015 1 commit
  18. 16 Oct, 2015 1 commit
  19. 29 Jul, 2015 1 commit
  20. 19 Mar, 2015 1 commit
    • Matt Turner's avatar
      mesa: Replace _mesa_round_to_even() with _mesa_roundeven(). · dd0d3a2c
      Matt Turner authored
      
      
      Eric's initial patch adding constant expression evaluation for
      ir_unop_round_even used nearbyint. The open-coded _mesa_round_to_even
      implementation came about without much explanation after a reviewer
      asked whether nearbyint depended on the application not modifying the
      rounding mode. Of course (as Eric commented) we rely on the application
      not changing the rounding mode from its default (round-to-nearest) in
      many other places, including the IROUND function used by
      _mesa_round_to_even!
      
      Worse, IROUND() is implemented using the trunc(x + 0.5) trick which
      fails for x = nextafterf(0.5, 0.0).
      
      Still worse, _mesa_round_to_even unexpectedly returns an int. I suspect
      that could cause problems when rounding large integral values not
      representable as an int in ir_constant_expression.cpp's
      ir_unop_round_even evaluation. Its use of _mesa_round_to_even is clearly
      broken for doubles (as noted during review).
      
      The constant expression evaluation code for the packing built-in
      functions also mistakenly assumed that _mesa_round_to_even returned a
      float, as can be seen by the cast through a signed integer type to an
      unsigned (since negative float -> unsigned conversions are undefined).
      
      rint() and nearbyint() implement the round-half-to-even behavior we want
      when the rounding mode is set to the default round-to-nearest. The only
      difference between them is that nearbyint() raises the inexact
      exception.
      
      This patch implements _mesa_roundeven{f,}, a function similar to the
      roundeven function added by a yet unimplemented technical specification
      (ISO/IEC TS 18661-1:2014), with a small difference in behavior -- we
      don't bother raising the inexact exception, which I don't think we care
      about anyway.
      
      At least recent Intel CPUs can quickly change a subset of the bits in
      the x87 floating-point control register, but the exception mask bits are
      not included. rint() does not need to change these bits, but nearbyint()
      does (twice: save old, set new, and restore old) in order to raise the
      inexact exception, which would incur some penalty.
      Reviewed-by: Carl Worth's avatarCarl Worth <cworth@cworth.org>
      dd0d3a2c
  21. 25 Jan, 2015 1 commit
    • Jason Ekstrand's avatar
      nir: add new constant folding infrastructure · 89285e4d
      Jason Ekstrand authored
      
      
      Add a required field to the Opcode class, const_expr, that contains an
      expression or statement that computes the result of the opcode given known
      constant inputs. Then take those const_expr's and expand them into a function
      that takes an opcode and an array of constant inputs and spits out the constant
      result. This means that when adding opcodes, there's one less place to update,
      and almost all the opcodes are self-documenting since the information on how to
      compute the result is right next to the definition.
      
      The helper functions in nir_constant_expressions.c were taken from
      ir_constant_expressions.cpp.
      
      v3 Jason Ekstrand <jason.ekstrand@iastate.edu>
       - Use mako to generate one function per opcode instead of doing piles of
         string splicing
      
      v4 Jason Ekstrand <jason.ekstrand@iastate.edu>
       - More comments and better indentation in the mako
       - Add a description of the constant expression language in nir_opcodes.py
       - Added nir_constant_expressions.py to EXTRA_DIST in Makefile.am
      Signed-off-by: Jason Ekstrand's avatarJason Ekstrand <jason.ekstrand@intel.com>
      Reviewed-by: Connor Abbott's avatarConnor Abbott <cwabbott0@gmail.com>
      89285e4d