Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8203696

Sweep x86_64.ad for better bitwise tests with imm{8,16,32,64} constants

XMLWordPrintable

    • Icon: Enhancement Enhancement
    • Resolution: Unresolved
    • Icon: P4 P4
    • tbd
    • 11
    • hotspot

      John says here:
        http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2018-May/029084.html

      I think it's doable; you define a constant operand type for the matcher
      which is 64 bits but whose value can be expressed with a 32-bit encoding.
      Actually, that's what this one appears to do:

         instruct loadUI2L(rRegL dst, memory mem, immL_32bits mask)
           match(Set dst (AndL (ConvI2L (LoadI mem)) mask));

      But the ConvI2L keeps it from being general. I guess there is an x86
      encoding issue with doing a true LoadL through a mask; I don't see
      any assembler forms for masked tests except for byte (cmpb), which you
      are filling in. For unmasked compares there are compares of memory
      to literal of all sizes (cmp[bwlq]). Do we cover those in the AD file?

      For testing a single bit, a test of any word size in memory could be
      strength-reduced to a byte test with an appropriate offset (0..7) and
      shifted imm8 byte constant (>>> 8*[0..7]). Doing that would be useful
      for some metadata bit tests, such as the upcoming Class.isValueType,
      as well as existing stuff like Class.isInterface. This should be doable
      in the AD file as well. (Any IR-level narrowing of the memory type
      would confuse alias analysis; this should be a private decision inside
      the encoding of one matcher rule.)

      We could parley your in-memory bit test into those other bit tests also.
      That would triple the complexity of your patch, so it can be done in a
      separate change; nevertheless I'd like to see it happen.

      16-bit is pretty marginal. byte/int/long are the important types. But the
      single-bit test hack (extended to an imm8 mask test) that I suggested above
      should be applied to all sizes.

      Point-fixes for particular code shapes are great. Those often drive us to
      improve optimizations not just for the particular code shapes but for some
      reasonable superset of those shapes. Roland's strip mining work is a good
      example. As we close up some holes in an optimization (load through mask
      then test), let's think briefly about removing the remaining known holes in
      that same optimization, to see if there is low-hanging fruit we can pick at
      the same time.

            Unassigned Unassigned
            shade Aleksey Shipilev
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: