This is an archive of the discontinued LLVM Phabricator instance.

[IntegerAttr] Add helpers for working with LLVM's APSInt type.
ClosedPublic

Authored by lattner on May 18 2021, 10:23 AM.

Details

Summary

The FIRRTL dialect in CIRCT uses inherently signful types, and APSInt
is the best way to model that. Add a couple of helpers that make it
easier to work with an IntegerAttr that carries a sign.

This follows the example of getZExt() and getSExt() which assert when
the underlying type of the attribute is unexpected. In this case
we assert fail when the underlying type of the attribute is signless.

This is strictly additive, so it is NFC. It is tested in the CIRCT
repo.

Diff Detail

Event Timeline

lattner created this revision.May 18 2021, 10:23 AM
lattner requested review of this revision.May 18 2021, 10:23 AM
rriddle accepted this revision.May 18 2021, 10:38 AM
rriddle added inline comments.
mlir/lib/IR/BuiltinAttributes.cpp
265–266

As an aside, I'm not really convinced that the existing asserts are all that desirable TBH.

This revision is now accepted and ready to land.May 18 2021, 10:38 AM
lattner marked an inline comment as done.May 18 2021, 10:51 AM

Thank you for the quick review!

mlir/lib/IR/BuiltinAttributes.cpp
265–266

I'm not sure about that in this case at least, I don't think this is a tradeoff of predictability vs convenience: if you have an attribute that might be signless, then it isn't the right thing to turn it into an APSInt and do stuff with it (because APSInt has operations that are sign specific).

This helper could default signless to unsigned or something, but any time that happened it is probably a logic bug.

That said, the getSInt() / getUInt() methods are huge footguns because they truncate to 64-bits. They should probably be removed. I don't think getUInt is even called in tree.

This revision was landed with ongoing or failed builds.May 18 2021, 10:52 AM
This revision was automatically updated to reflect the committed changes.
lattner marked an inline comment as done.
rriddle added inline comments.May 18 2021, 11:13 AM
mlir/lib/IR/BuiltinAttributes.cpp
265–266

Definitely agree for APSInt. For getSInt/getUInt, getSExtValue/getZExtValue will assert if the number of active bits > 64. These also match the similarly named methods on llvm::ConstantInt. Removing/cleaning up the asserts would also allow merging getInt into getSInt.

On usage, getSInt/getUInt aren't used that heavily inside of google, but getInt is. I chock that more up to the fact that the asserts require signed/unsigned, and signless is the most prevalent of the integer types.