[PATCH] D76878: Implement new DW_OP_LLVM_* operations

[Paul Robinson via Phabricator via llvm-commits]

probinson added a comment.

In D76878#1960563 <https://reviews.llvm.org/D76878#1960563>, @scott.linder wrote:

> Right, I think with so few vendor encodings left there has to be some mechanism for reusing them or opening up the encoding space. Just increasing the vendor extension range will eat into the already dwindling standard encoding space. We also tried really hard to make the entire proposal backwards compatible, and switching to ULEB128 seems like a hard break in compatibility as the 7th bit is already active in `DW_OP_`'s even in the non-user range. Maybe reserving a single `DW_OP_` to say "what follows is a ULEB128 extended-opcode" would be feasible, although it would still have a pretty far reaching impact.


That's what DWARF does for line-number program opcodes; opcode 0 indicates an "extended" opcode, with a ULEB guarding the whole thing so it can be skipped by consumers who don't recognize it.  If the expression opcode space is feeling the squeeze (which I can easily imagine, as there are only 32 opcodes in that space) it would seem like a reasonable extension to do the same thing in the DWARF expression space.

For your implementation, you would want to use one of the existing user-range opcodes, but you could define that as introducing the extended-opcode encoding.  Please model it on how line-number extended opcodes work.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76878/new/

https://reviews.llvm.org/D76878