You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@farzonl@Keenuts I don't think it's an issue. We can't pass bit width other than 32 with IDRegClass, because this register class is defined to hold 32 bit width values, please see
def ID : RegisterClass<"SPIRV", [i32], 32, (add ID0)>;
As a more general note, bit width for integers in SPIR-V backend works in a consistent manner when we are talking about generated instructions. Otherwise, in case of low-level types, registers, register classes and register banks, we are dealing with an abstraction that doesn't relate LLVM low-level types and user data types, but rather is using low-level types for Tablegen-driven instruction selection.
I created the bug to track the todo I saw in the code base and there was some evidence to suggest bit width was important here. If that isn't the case then this ticket should change to remove the todos and to fix the case I linked above to just do 32 bit width.
@farzonl I agree that there is a space for improvements here. However, the context is wider than just this example, and my comment above was related mainly to the incorrect "crash" classification of this issue. It's not a crash, I'd remove this label as confusing, but rather a part of the bigger question -- how do we use LLT with Tablegen instruction selection. I'd say that we may want to create a bigger TODO item (probably, a lower priority one) to improve usage of Tablegen for instruction selection, including this particular case of bit width in LLT.
There is a prexisting TODO on this, but no issue tracking it
so this issue will become the tracking.
Below is the stacktrace:
Originally posted by @farzonl in #87952 (comment)
@Keenuts for awareness.
The text was updated successfully, but these errors were encountered: