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
Hello, I'm working with Debjit's research team. We were interested in doing is adding large bit integers to Allo, but we were having some difficulties. I saw that the AlloType class inside types.py prohibited integers > 2047 in size, and that made me wonder: is this a safeguard for the MLIR code? Is there some limitation within MLIR on integers larger than 2047 bits?
To try and get around it, I first tried to define my own class [1] and pass around the typing rules, but I was unfortunately caught by typing_rule.py:123 because that uses type() to get the class, and I don't know if it's possible to get around that.
Are we headed in the right direction? Is this compatible with the MLIR? What is another approach we could take, if any?
Hi @Arsalan-Zahid, thanks for your interest in our project. You do not need to define a new class to support larger bitwidths but can simply remove this guard. For example, by running the following code, you can generate the corresponding MLIR module.
However, you cannot pass in data into it to verify the correctness using the LLVM backend, as it highly depends on the C data types and the NumPy package that cannot natively support such large bitwidth integers.
Hello, I'm working with Debjit's research team. We were interested in doing is adding large bit integers to Allo, but we were having some difficulties. I saw that the AlloType class inside types.py prohibited integers > 2047 in size, and that made me wonder: is this a safeguard for the MLIR code? Is there some limitation within MLIR on integers larger than 2047 bits?
To try and get around it, I first tried to define my own class [1] and pass around the typing rules, but I was unfortunately caught by typing_rule.py:123 because that uses type() to get the class, and I don't know if it's possible to get around that.
Are we headed in the right direction? Is this compatible with the MLIR? What is another approach we could take, if any?
@paldebjit @chhzh123 @zzzDavid
[1]
The text was updated successfully, but these errors were encountered: