[PATCH] D79190: llvm rejects DWARF operator DW_OP_lit[1-31] in IR

Fri May 1 17:13:33 PDT 2020

dblaikie added a comment.

In D79190#2014586 <https://reviews.llvm.org/D79190#2014586>, @alok wrote:

> In D79190#2013650 <https://reviews.llvm.org/D79190#2013650>, @probinson wrote:
>
> > If I take your C input program and compile it to a .o file, I see that we do emit (DW_OP_lit13; DW_OP_lit0; DW_OP_mul; DW_OP_stack_value) for "var2".
> >
> > I think what you are saying is, we do not accept DW_OP_litN as *input* in the IR.  Is that correct?  If so, please make sure the commit log states that.
>
>
> Yes correct. The C program works because clang generates "DW_OP_constu, 5", which is optimized to DW_OP_lit5, but it doesnt accept DW_OP_lit5 in IR. I missed to state that clearly in commit log. I shall update the commit log. Thanks for your review.
>
> In D79190#2014425 <https://reviews.llvm.org/D79190#2014425>, @aprantl wrote:
>
> > I think this may actually be to some degree intentional. In LLVM IR. What's the use-case for this? Currently in LLVM IR a constant is always represented by a DW_OP_const(u) which makes the expressions easier to parse. LLVM knows how to *emit* DW_OP_litX, but I'm not sure what we gain from accepting it in LLVM IR.
>

The inverse argument might be that keeping the LLVM IR in a more singular/canonical form will better for a semantic representation that's expected to be handled/mutated through the optimizations, then lowering to whatever is optimal at the end.

@aprantl - when this stuff was added, do you recall if there was any particular goal around that? Was lit0 added for some specific reason/separate from adding litN? Or was it just an oversight? And/or do you have thoughts on which way this should go today?

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79190