Hi I’m handling CFG issues in work, in which I may need to create a big map (based on current construction, I cannot figure out a better way), or if I may, adding an attribute, even simply a pointer to the block could help.
Thus I would like to ask if there is a possibility of attaching some information on a block??
There isn’t a way to store attributes on a block right now.
I’ve run in to the desire to have something like this when doing various CFG-based specializations. Within a single pass, a side map is fine, but it does bias these types of algorithms to mondo-passes vs more fine grained parts.
In isolation, it wasn’t enough for me to propose adding something here. Just adding my experience as additional anecdote.
Is it for debugging or for functionality? Is its lifetime (of use) fully contained inside of a pass/utility or across passes?
In the case I ran into this, I constrained it to a single pass but could see wanting to have a couple of passes working together – in which case you really need to be persisting something in the IR (in my case, it would be which blocks were original vs which were speculatively specialized). What I was working on was just a toy – but it didn’t take long to hit the constraint.
One way to handle this (depending on the use-case) is to create a pass specific op and drop it into the block in question. That op can have attributes and other things attached to it, and you can remove it in later passes. This gives you full ability to persist things into the IR, is fully extensible, and usually works well with passes that ignore things they don’t understand.
Hi it is mainly for some special handle for some variables. If that block is added with special handling code for variable
a, then it should not be re-added…
Hi problem is that our pass is based on module, and the compile time also matter, it costs more for finding a block and compare it within the block in map…
Hi what about I simply add a pointer in block class… May it be safe??
Hi, what about simply add a
void* in block class??? Would there be any dependency that sensitive for that, if I do it myself???
That’s not something we would want to take in mainline MLIR. If you need extra metadata, please use a side table like a DenseMap. You can even use an Analysis to keep things live across passes.
So it sounds like effectively you want to simulate a work queue at block level granularity using attributes? Is there a reason to not just have it explicitly be a work queue/have it persist in the IR across passes? (It would seem to be more efficient than doing vanilla walks and then filtering).
Analysis is a way if it needs to persist (you just have to ensure the analysis is retained until use or can easily be recreated). Another alternative (which has some potential issues) is to use a convention, such as tagging the op that the region is associated with with a discardable attribute consisting of an array of attributes corresponding to the attributes of the regions. Downside to this is that well they may get discarded (same as Analysis) or get out of date (e g., there is no automatic invalidation) so ensure the passes between addition and use retain it.
Hi, thanks for answering.
Hmmmmm, my situation is like this:
- Some of the variable need to be reset to its original value for some reason
- The variable should be reset at some specific quitting block (not only return, but also call or indicated by some other specific
- If the variable not changed, there is no need to reset it. For saving cost, it will start from
operation that changed the variable, and finding the quitting block recursively.
- I have to scan all the code to decide which variable need to be reset
So, with the current situation, I would either need a map indicating that variable
a has been reset in block
1,2,3....; or I can put
a in block
1,2,3 to avoid big map…
BTW, I’ve searched the doc and trying to find
analysis, is there any documentation in indicating how to use it??
(In web search, you can use: