Ior examples

[mmc28a]

No description provided.

[skvadrik]

Hi! Thanks for working on this on behalf of the AOSP team.

We are using MacroAssembler to generate code in the compiler. We need use/def information for each instruction in order to analyse manually generated assembly code for possible register clobbering issues. To check if we have issues, we want to construct a shadow control flow graph that would have the generated macro-instructions in the basic blocks, and analyse use/def flow on that graph. Omitting further details, we need to get use/def information from every macro instruction that we generate.

This PR makes it possible, and the interface looks good, except for one detail: we would need to run an extra decoder pass on the generated code in order to get that information. It would be more convenient for our use case to be able to query that information from the MacroAssembler itself (if it could record the information at the time when a macro-instruction is generated). Would it be too hard / not worth the effort to support?

[mmc28a]

Hi. Thanks for taking a look.
I'm wondering if you have any performance constraints on your application, such that a decoder pass of generated code is too expensive?
Also, what would you expect the MacroAssembler interface to look like? A cumulative report of registers read/written, with a reset method, like the API in this patch?

[skvadrik]

I'm wondering if you have any performance constraints on your application, such that a decoder pass of generated code is too expensive?

No, this will be debug-only code, so for our purposes this will be ok. My question was mostly to check if it will be easy/reasonable for you to move this logic to the MacroAssembler instead of Decoder.

Also, what would you expect the MacroAssembler interface to look like? A cumulative report of registers read/written, with a reset method, like the API in this patch?

The goal is to construct a control flow graph with use/def statements in the basic blocks. In essence, just the assembly program represented as a graph, all irrelevant information filtered out. (If you wonder why we may want this: we want to generate a mirror program on virtual registers instead of hardware ones, with an unbounded number of virtual registers, and put that program in SSA form. Then we will check if some hardware register maps to different virtual registers, one of which is defined while the other one is still used --- this means that the assembly code clobbers the hardware register.) To construct such a graph, we will need to dump use/def information for every instruction, or maybe for blocks that span between control-flow changing instructions like B and IT.

[mmc28a]

Thanks for the explanation. I think moving the logic into the macro assembler isn't easy, and makes impossible one of the applications I'd considered: analysis of externally-generated instructions.

I'll think about how we might add a similar feature to the macro assembler, for use during generation. I expect it'll use the code in this pull request to generate instrumentation in the macro assembler, so I can share some of the rules and testing. However, I'm unlikely to get to producing something in this area until 2023.

[skvadrik]

Sounds good, there's definitely no rush on our side. Thanks for your work!