`llvm.add` is interpreted as `llvm.addrspacecast`
This feels like it's not working correctly, considering add is documented as something else.
62 Replies
Can you share the actual docs on LLVM dialect for this Op?
I also find that the translation between Mojo syntax to dialect is a black box to us
For eg the index.casts index.castu syntax are different from Mojo's
this is why they're different
![No description](https://cdn.answeroverflow.com/1151139509245853778/image.png)
both llvm and index dialects are off by one
at least that's what it looks like :D
well, sometimes
Congrats @TeamPuzel, you just advanced to level 13!
it seems like you have to use the one before what you actually want
'llvm' Dialect - MLIR
Multi-Level IR Compiler Framework
it's the second one
whichever one I use mojo seems to take the next
![No description](https://cdn.answeroverflow.com/1151140992158801990/image.png)
This is quite funny. On my machine, I can't seem to use anything from the llvm dialect (and haven't tried to before), it can't find the llvm.add and other __mlir_ops, but the index dialect works fine and isn't one off as yours seems to be. For example, I can run the following, and it prints
64
:
Okay, now I get the same one-off error with llvm dialect. Strange.
(just in case, my mojo --version is mojo 0.2.1 (64d14e85)
)odd, I have the exact same version
Not all of them are one off which makes it even more weird to me
Though if I actually try to use llvm.ashr (which I assume must be add for me) it gives me an
add
error!First my LSP says that llvm.add is unregistered, then running it in console says llvm.addrspacecast wants a single operand.
Yeah, I'm using ssh into a linux laptop with too little ram to handle the lsp so I don't even see those :D
if you use ashr you will get add
On my end it crashes if I replace add with ashr
🤷♂️
unfortunately trying to add i32 in this way crashes llvm
Yep lol