diff options
author | Bruno Cardoso Lopes <bruno.cardoso@gmail.com> | 2025-10-13 11:10:59 -0700 |
---|---|---|
committer | GitHub <noreply@github.com> | 2025-10-13 11:10:59 -0700 |
commit | 34c0a5f1b44172de0a9464356b12bd7f6c25023c (patch) | |
tree | 9789d85af1868957c603b5e0be105e0250507b41 /llvm/lib/Support/SourceMgr.cpp | |
parent | 8d29a3bb6f3d92d65bf5811b53bf42bf63685359 (diff) | |
download | llvm-34c0a5f1b44172de0a9464356b12bd7f6c25023c.zip llvm-34c0a5f1b44172de0a9464356b12bd7f6c25023c.tar.gz llvm-34c0a5f1b44172de0a9464356b12bd7f6c25023c.tar.bz2 |
[MLIR][LLVM] Add bytecode support for several attributes (#162577)
For a total of 20 attributes, 18 debug information related + 2 regular
ones (loop and alias_scope).
Quick background on how this work: if a given attribute isn't supported,
by default its textual form is dumped into the bytecode. In order to get
proper encoding, an attribute needs a tablegen description of it and its
element. There's an additional rule here: if an attribute is only used
by another attribute, it's user need also to have an encoding in order
for it to be encoded. (e.g. `DICompileUnitAttr` only gets encoded while
in `DISubprogramAttr` if the later also has an encoded form), otherwise
text is used. For this reason, this PR does a bunch at the same time,
otherwise there isn't really much to test (easy to break it down if
needed though).
The PR is tested against some of our internal apps, successfully
round-tripping around 14Gb of llvm dialect text. Some interesting
findings include a 800K mlir textual file that used to become 1.2G in
bytecode format - now down to 100K due to proper encoding of debug info
attributes.
In the future we should find a way to merge this together in the
attribute definitions (perhaps autogenerate the entries from LLVM
attribute descriptions), seems like we can benefit from the boilerplate.
It's not clear yet how to solve some of the tablegen issues; some fields
require manual translation of flag values using `LocalVar`, others
require custom getters, etc. Ideas on that front are welcome.
A next natural step here is to add type support, LLVM structs can also
lead to non-neglible disk footprint.
Diffstat (limited to 'llvm/lib/Support/SourceMgr.cpp')
0 files changed, 0 insertions, 0 deletions