This is an archive of the discontinued LLVM Phabricator instance.

[mlir] BitEnum attributes: width parameterization, default/optional value support
AbandonedPublic

Authored by jfurtek on Apr 4 2022, 3:15 PM.

Details

Summary

This diff contains improvements to generic BitEnum functionality for
future use by fastmath attributes in the arithmetic dialect.

In this diff:

  • Parameterization of bit enum attributes in OpBase.td by bit width (e.g. 32

and 64). Previously, all enums were 32-bits. This brings enum functionality in
line with other integer attributes, and allows for bit enums greater than 32
bits.

    • SPIRV and Vector dialects were updated to use bit enum attributes with an explicit bit width
  • The EnumAttr tablegen class was modified to use an alternate class derived from AttrParameter when a bit enum attribute is declared. The parameter parse() function is customized for bit enum attributes.
  • TableGen modifications:
    • Modified OpDefinitionsGen.cpp to generate additional build() functions for ops that have default values AND use an operand to determine the result type. (This is necessary to avoid modifying conversion code that creates operations with default-value attributes without actually specifying a value for that attribute.)
    • Modified OpPythonBindingGen.cpp to allow None arguments for default- valued attributes. (Previously, None was only allowed for optional attributes.) This is necessary to avoid modifying existing, in-tree Python tests that do not specify a fastmath value.
    • Addition of a new field for bit enum attributes: printBitEnumPrimaryGroups, which is (optionally) used to avoid redundant printing of bits that are contained by a "full" group. As an example, when printBitEnumPrimaryGroups is set to 1, the fastmath value would print as simply "fast", instead of printing all bit values: "reassoc,nnan,ninf,nsz,arcp,contract,afn,fast".

Diff Detail

Event Timeline

jfurtek created this revision.Apr 4 2022, 3:15 PM
jfurtek requested review of this revision.Apr 4 2022, 3:15 PM

Added @Mogball, since he was working on the future of the Enum ODS infra

jfurtek abandoned this revision.Apr 4 2022, 3:27 PM

Apologies @mehdi_amini - I didn't see your previous "breakdown" recommendation until after I started the follow-up. Let me abandon this and try one more time with "even more" trimming...

Apologies @mehdi_amini - I didn't see your previous "breakdown" recommendation until after I started the follow-up. Let me abandon this and try one more time with "even more" trimming...

I just suggested something, you don't have to adhere exactly, the revision here seemed like reasonable. That said if it isn't too painful to split it further, please do :)