Support for `blockaddress`

Hi All,

Hope you are doing well!

I have recently encountered the need to use the address of a block in MLIR.
In particular, I am working with a target specification that supports operations that set “jump targets” akin to interrupt handlers if you will.

Right now, I am forced to create proxy ops as a workaround. These ops will then
acquire their blockaddress later in the llvm backend component (outside of MLIR).
It is certainly possible to do this at the moment but it creates fragmentation in our infrastructure that it is at least inconvenient. Also, if I’m not mistaken, this will be a blocker for us if we ever want to allow these “jump targets” to be set explicitly by the users of our high-level language. Thankfully this is not the case quit yet.

Would appreciate any feedback and would be more than happy to help on that front if needed :slight_smile:

Thank you in advance!

+1 on this (Block address will help in the implementation of indirectbr and callbr in LLVM Dialect). There has been some discussion about whether or not to support the entire LLVM IR in LLVM Dialect, but I am not sure what the consensus was.

If I understand correctly, one of the challenges here is that Basic Blocks are not Values in MLIR, therefore they don’t have types and they cannot be used as an operand.

The only way to link a BB to an Operation is to use the successor field, which would require the operation to be a terminator?

1 Like

Other fundamental problems come into play depending on where you would want to use a blockaddress, e.g. in LLVM you can use a blockaddress in a global initializer. In MLIR, that would require referencing a block outside of the scope that it is defined. It also gets even weirder if you consider nested regions that aren’t symbols (e.g. a loop inside of a function).

– River

2 Likes