)]}'
{
  "commit": "ad23611856453012ac644aecc91a42c4df54192e",
  "tree": "44d5bb4199bf2e9606a56933d38d5f6ca3a66695",
  "parents": [
    "27be42f696e5c6c98d31243cbcc8a169edb18a84",
    "05f29e2cae7a6f06ab15ed94b195e5f4ff4277cf"
  ],
  "author": {
    "name": "Ben Vanik",
    "email": "ben.vanik@gmail.com",
    "time": "Mon Dec 05 23:12:38 2022 -0800"
  },
  "committer": {
    "name": "GitHub",
    "email": "noreply@github.com",
    "time": "Mon Dec 05 23:12:38 2022 -0800"
  },
  "message": "Adding plumbing and samples of custom CUDA/SPIR-V/CPU dispatch code. (#11287)\n\nThis adds a skeleton workflow for declaring external objects that are\r\nable to be referenced by the compiler all the way from the high-level\r\ndialects (flow, at least) and a sample demonstrating how device\r\nfunctions in .cu, .glsl, and .o files can be connected end-to-end with\r\nexecution. The end goal is to allow codegen backends - including\r\nextensions - to either select from precompiled object files or\r\ngenerate/JIT their own as part of translation.\r\n\r\nThe core feature added is the `#hal.executable.object` attribute that\r\nallows executable variants to have extra object files specified:\r\n```mlir\r\nhal.executable private @executable {\r\n  // Variant linking in an x86-64 object file containing external functions.\r\n  hal.executable.variant public @x86_64, target \u003d #x86_64_target, objects \u003d [\r\n    // Object files linked into the executable.\r\n    #hal.executable.object\u003c{\r\n      // Referencing a file path on disk but could also have the data embedded.\r\n      path \u003d \"samples/custom_dispatch/cpu/embedded/functions.o\"\r\n    }\u003e\r\n```\r\nThe attribute also allows for data to be directly embedded and (in the\r\nfuture) specified via MLIR external resources. When using file paths\r\neither the absolute path, a path relative to the current working\r\ndirectory, or a relative path joined with search paths will be tried.\r\n`--iree-hal-executable-object-search-path\u003d` can be specified multiple\r\ntimes to add to the search paths.\r\n\r\nThis can be extended as required for new backends (.metallibs and\r\narchives) as well as various formats for the existing ones (linking .spv\r\nfiles together, .bc instead of .o for LLVM IR, etc). There\u0027s some work\r\nto be done around interactions with linking phases that may limit the\r\nusefulness of these stages for cross-compilation but at least for now we\r\ncan rely on a bleeding-edge user wanting to hand-author these dispatch\r\nfunctions not caring about it yet. Since objects are specified\r\nper-variant it\u0027s possible for a user to still cross-compile and\r\nmulti-target just with a bit more IR (today). It\u0027s also possible to\r\nspecify the objects at the stream level and (if we have a good story for\r\ntensor -\u003e pointers) we could allow it at the flow/input-level too.\r\n\r\nSome future ergonomics improvements are tracked in #11289.\r\nIn particular there will be a way to avoid the boilerplate the CPU side\r\nrequires by having us generate that automatically for some very basic\r\ninterfaces (limited access to workgroup params and the environment).",
  "tree_diff": []
}