[BOLT][NFC] Add allocator id to createInstrIncMemory #68709
Conversation
On RISC-V, this function will have to insert `auipc`+`lw`/`sw` pairs where the `auipc` needs a label annotation (see llvm#66395). In order to do this correctly within the context of `ParallelUtilities`, we need an allocator id when setting the label. This patch adds this allocator id argument and wires it through to all call sites. Note that this function is also made non-const since `setLabel` is non-const.
|
Overall LG, but probably needs riscv implementation, since by it's own seems to be meaningless.. |
That will be part of the PR implementing instrumentation for RISC-V. Still waiting for a few dependent patches to land before submitting that one. |
rafaelauler
left a comment
rafaelauler
left a comment
There was a problem hiding this comment.
FYI instrumentation pass is not running in parallel
This really confused me but now I see that Is it guaranteed that this will always be the case? If so, this PR isn't necessary. Just for my information: why is |
|
At the time I tought it would be good to have it ready to run in parallel because I couldn't tell how expensive it would be to run the instrumentation pass. But eventually I realized I had little gains from running this in parallel so I just turned it off, but kept the scaffolding for parallel execution "just in case" we need to revisit this. I know realize this was silly, and we can just take that off. |
|
Thanks for the explanation, @rafaelauler! I think this can be closed now, especially once #70147 gets merged. |
3 participants
On RISC-V, this function will have to insert
auipc+lw/swpairs where theauipcneeds a label annotation (see #66395). In order to do this correctly within the context ofParallelUtilities, we need an allocator id when setting the label. This patch adds this allocator id argument and wires it through to all call sites.Note that this function is also made non-const since
setLabelis non-const.