Changing HAL dialect syntax to express all types.

[benvanik]

The previous HAL ops inferred the types of the values they were working on (such as !hal.buffer or !hal.device); this prevented the specialization of those types required for buffer analysis and static device feature detection.

The new syntax uses op_name<%value : !hal.type> on the op name indicating that the op is templated on the given %value. Parameters are now mostly encoded in named parens like linalg to remove a lot of the parsing ambiguity that existed when they were comma separated. There's a few types that still need some cleanup (particularly hal.buffer_view), however those need a bit more bake time with the other changes in order to figure out the right way to handle them so they've been left unchanged here.

Future changes for allocation will use a !hal.buffer<device, type, access, etc> and changes for device feature
detection will use a !hal.device<@id>. Other types like !hal.command_buffer may also be specialized per-device.

There's some partially-updated enum support in here that will be getting improved in the follow-ups; the enums will move into the type specifiers and many of the enums used on ops will go away as well.

[ScottTodd]

Hm.. I'm wondering about the syntax (and printer/parser) of this op, and others like execution_barrier. Typically there would be commas or some other separator between arguments, instead of newlines, and some wrapper around the parameters like [ ], ( ), { }, < >. This certainly reads easily as a human though. WDYT?

[benvanik]

the newlines are optional (it just needs whitespace) - the syntax here matches linalg which has things like:

  linalg.generic #attrs
    ins(%A, %B: memref<?x?xf32>, memref<?x?xf32>)
    outs(%C: memref<?x?xf32>) {
    ^bb0(%a: f32, %b: f32, %c: f32):
      %d = addf %a, %b : f32
      linalg.yield %d : f32
    }

The commas and simple separators have ambiguity when parsing the nested types (which is why linalg does this too). Future PRs will change some of these enums to being type parameters instead, so the op will be %cmd = hal.command_buffer.create device(%device : !hal.device) : !hal.command_buffer<..., "OneShot", "Transfer|Dispatch"> (or something like that). Same with memory types and such for buffers - those will be on the return types instead of as op attributes.

[ScottTodd]

SG as long as there is precedent and a good reason :)

[ScottTodd]

Ah, this answers my question about the single character comments, I think. Could still add more context to the .td though.

[benvanik]

Yeah this is pulling some stuff from the future where buffer types use these - I'll continue refining them when we can produce IR that uses them and make some judgements about what makes sense. This first pass was done during my previous buffer allocation work when having 100k !hal.buffer<"HostVisible|DeviceLocal|DeviceVisible", "Constant|Transfer|Mapping", "Read|Write"> made my eyes bleed vs !hal.buffer<hD:CTM:RW>.

[ScottTodd]

Ok cool. Still seems worth a comment in the .td, perhaps with just that example you included

[ScottTodd]

(I still think a comment or some more documentation on the short string versions would be useful, but that can be added as this gets refined)

[ScottTodd]

_{(just commenting on this file to start a thread)}

Lots of test files are updated here. I hope that wasn't too much trouble. Do you think some of these tests were brittle / checking too many things unrelated to their core purpose, or is that just the nature of changing the syntax for widely used ops?

[benvanik]

Yeah these are all low level - ideally they'd be flow and above such that the HAL is an implementation detail. The tensorlist/strings modules are also touching the HAL directly for the same reasons.

[ScottTodd]

LGTM when builds pass

https://source.cloud.google.com/results/invocations/0fac8a3c-8912-4f01-8cee-30741057d4d3/targets/iree%2Fgcp_ubuntu%2Fbazel%2Flinux%2Fx86-swiftshader%2Fcore%2Fpresubmit/log

//iree/compiler/Conversion/LinalgToNVVM/test:distribute_to_thread.mlir.test FAILED in 6.7s

RUNLINE: // RUN: iree-opt -pass-pipeline="hal.executable(hal.executable.target(iree-codegen-cuda-tile-and-distribute))" %s | IreeFileCheck %s
RUNNING TEST: iree-opt -pass-pipeline="hal.executable(hal.executable.target(iree-codegen-cuda-tile-and-distribute))" iree/compiler/Conversion/LinalgToNVVM/test/distribute_to_thread.mlir | IreeFileCheck iree/compiler/Conversion/LinalgToNVVM/test/distribute_to_thread.mlir
----------------
iree/compiler/Conversion/LinalgToNVVM/test/distribute_to_thread.mlir:5:3: error: 'hal.executable.entry_point' op attribute 'ordinal' failed to satisfy constraint: size_t
  hal.executable.entry_point @add_dispatch_0 attributes {interface = @legacy_io, ordinal = 0 : i32, signature = (!flow.dispatch.tensor<readonly:1024xf32>, !flow.dispatch.tensor<readonly:1024xf32>, !flow.dispatch.tensor<writeonly:1024xf32>) -> ()}
  ^

[benvanik]

ah darn, new tests :)
I'll get it fixed/landed tonight after everyone heads out so I don't cause churn for people