[BOLT][NFC] Add allocator id to createInstrIncMemory

[mtvec]

On RISC-V, this function will have to insert auipc+lw/sw pairs where the auipc needs a label annotation (see #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.

[yota9]

Overall LG, but probably needs riscv implementation, since by it's own seems to be meaningless..

[mtvec]

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]

FYI instrumentation pass is not running in parallel

[mtvec]

FYI instrumentation pass is not running in parallel

This really confused me but now I see that ForceSequential=true is passed here.

Is it guaranteed that this will always be the case? If so, this PR isn't necessary.

Just for my information: why is ParallelUtilities even used if everything is executed sequentially?

[rafaelauler]

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.

[mtvec]

Thanks for the explanation, @rafaelauler! I think this can be closed now, especially once #70147 gets merged.