Not printing large resource blobs with mlir-print-ir*

stellaraccident · August 16, 2023, 3:17am

I’m working on eliminating our usage of DenseElementsAttr within our implementation, replacing it with variants that are based on dialect resource blobs. Things are going all right, but I’ve noted that our users make heavy use of --mlir-elide-elementsattrs-if-larger= with --mlir-print-ir* flags. This has always been a hack (imo) wired into the OpPrintingFlags, but a lot of people use it.

I’m trying to figure out how to produce a similar level of usability for IR printing with resources. I think we could wire up some kind of “skip dialect resources” and they would then effectively just be declarations when encountered in the IR and it would be up to individual implementations to ensure this meant something.

Any ideas what might be appropriate to do here (or whether something already exists)?

@jpienaar, @River707, @mehdi_amini who I know have done a lot of work in this area.

(edit: I suppose that if the AsmPrinter had access to the OpPrintingFlags, I could just cargo cult onto the existing limit and print a special form of my custom resource based ElementsAttr that is similarly elided. But I’m not sure how to get access to the flags. I see they are on the module-local Impl: could we expose a getter for that on the user-accessible AsmPrinter so that anyone, not just builtin types can use it?)

mehdi_amini · August 16, 2023, 5:31am

Isn’t printing the resource content under control of the dialects? That is a dialect can print them in the IR or print a reference to a file, or …

By the way this (resource) is the only (?) feature of MLIR (Core) that is not documented, if you end up as part of your work to something that be the basis of a new tutorial chapter, or at least a documentation page, it’d be welcome!

stellaraccident · August 16, 2023, 5:49am

Yes – I guess I was fixated on using the existing carve out in the OpPrintingFlags. But you are right there are other ways. Do you consider the existing flag for eliding large elements to be legacy? If not, I don’t think we should have it so that only the built-in types can use it. As it stands right now, I can’t define my own ElementsAttr with the same level of support as the built-in attribute.

I noticed I’ve spent a significant amount of time figuring out how it all fits sufficient for me to build what I want. Almost there.

It would be nice if we had an example other than DenseResourceElementsAttr – it is hard to see all of the moving parts and how to do them in your own dialect. It took me quite a bit of time to get the callbacks for both ASM and bytecode working right.

Let me get my implementation done and assess. I agree this needs docs/examples.

stellaraccident · August 16, 2023, 3:25pm

I think another under documented area: the declarative bytecode definitions such as are used in the built-in dialect. Are those documented somewhere?

github.com

llvm/llvm-project/blob/main/mlir/include/mlir/IR/BuiltinDialectBytecode.td

//===-- BuiltinBytecode.td - Builtin bytecode defs ---------*- tablegen -*-===//
//
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
// See https://llvm.org/LICENSE.txt for license information.
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
//
//===----------------------------------------------------------------------===//
//
// This is the Builtin bytecode reader/writer definition file.
//
//===----------------------------------------------------------------------===//

#ifndef BUILTIN_BYTECODE
#define BUILTIN_BYTECODE

include "mlir/IR/BytecodeBase.td"

def LocationAttr : AttributeKind;
def ShapedType: WithType<"ShapedType", Type>;

This file has been truncated. show original

mehdi_amini · August 27, 2023, 3:54am

@jpienaar pointed me here: Defining Dialects - MLIR