search

DynamoRIO / dynamorio

Dynamic Instrumentation Tool Platform
Other
2.61k stars 554 forks source link

[AArch64] Split OP_prfm opcode, or provide named constants for the sub-opcode immediate operand #4388

Open derekbruening opened 4 years ago

derekbruening commented 4 years ago

See the discussion at https://github.com/DynamoRIO/dynamorio/pull/4386#discussion_r462356954 regarding opcode philosophy of separate opcodes for separate semantics.

This issue covers either splitting the OP_prfm opcode into OP_prfm_read_l1, OP_prfm_read_l1_nt, etc., with a helper to determine whether an opcode is a PRFM, or leaving the single OP_prfm and providing a named enum where DR_PRFM_READ_L1_NT, etc. are set to equal their encoded 5-bit immediate value in the source operand. Both approaches avoid the bit decoding currently at https://github.com/DynamoRIO/dynamorio/blob/master/clients/drcachesim/tracer/instru.cpp#L82 and we'd want to update that code with the result. We have pros and cons of both approaches; splitting the opcodes is a compatibilty break as well. Whoever takes on the work gets to pick the approach I suppose.

derekbruening commented 4 years ago

It's sounding like we have more votes for the single OP_prfm here: so we're considering the DC cache management types to be semantically different enough for separate opcodes, but not the prefetch types (nor the various SIMD operation variations we don't split inside the same opcode).

derekbruening commented 4 years ago

Xref #4393 which is a pre-req for opcode splitting.