<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><span class=""><div>Makes sense. If I understand your comment correctly, the following snippet:<br></div></span></div><div><br></div><div>%1 = ...</div><div>%token = call llvm.dbg.value(token %undef, %1, !var, !())</div><div>%2 = ...</div><div>call llvm.dbg.value(token %token, %undef, !var, !())</div><div>call llvm.dbg.value(token %undef, %2, !var, !())</div><div><br></div><div>is equivalent to</div><div><br></div><div><div>%1 = ...</div><div>call llvm.dbg.value(token %undef, %1, !var, !())</div><div>%2 = ...</div><div>call llvm.dbg.value(token %undef, %2, !var, !())</div><div><br></div></div><div>and both are legal.</div></div></blockquote><div> </div><div>Yes</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><div class="h5"><br><blockquote type="cite"><div><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>> > ><br>> > >     - To add a location with the same value for the same variable, you<br>> > pass the<br>> > >       token of the FIRST llvm.dbg.value, as this llvm.dbg.value's first<br>> > argument<br>> > >       E.g. to add another location for the variable above:<br>> > ><br></span>> > >         %second =3D call token @llvm.dbg.value(token %first, metadata<br><span>> > %val2,<br>> > >                                             metadata !var, metadata<br>> > !expr2)<br>> ><br>> > Does this invalidate the first location, or does this add an additional<br>> > location<br>> > to the set of locations for var at this point? If I want to add a third<br>> > location,<br>> > which token do I pass in? Can you explain a bit more what information the<br>> > token<br>> > allows us to express that is currently not possible?<br>> ><br>><br>> It adds a second location. If you want to add a third location you pass in<br>> the first token again.<br>> Thus the first call (key call) indicates a change of values, and all<br>> locations that have the same value should use the key call's token.<br>><br><br></span>Ok. Looks like this is going to be somewhat verbose for partial updates of SROA’ed aggregates as in the following example:<br><br>// struct s { int i, j };<br>// void foo(struct s) { s.j = 0; ... }<br><br>define void @foo(i32 %i, i32 %j) {<br> <span> </span>%token = call llvm.dbg.value(token %undef, %i, !Struct, !DIExpression(DW_OP_bit_piece(0, 32)))<br>           call llvm.dbg.value(token %token, %j, !Struct, !DIExpression(DW_OP_bit_piece(32, 32)))<br> <span> </span>...<br><br> <span> </span>; have to repeat %i here:<br> <span> </span>%tok2 = call llvm.dbg.value(token %undef, %i, !Struct, !DIExpression(DW_OP_bit_piece(0, 32)))<br>         <span> </span>call llvm.dbg.value(token %tok2, metadata i32 0, !Struct, !DIExpression(DW_OP_bit_piece(32, 32)))<br><br>On the upside, having all this information explicit could simplify the code in DwarfDebug::buildLocationList().<br></blockquote><div><br></div><div>Yeah, this is true. We could potentially extend the semantics by allowing separate key calls for pieces, i.e.</div><div> </div><div>%token = call llvm.dbg.value(token %undef, %i, !Struct, !DIExpression(DW_OP_bit_piece(0, 32)))<br>           call llvm.dbg.value(token undef, %j, !Struct, !DIExpression(DW_OP_bit_piece(32, 32)))<br></div><div><br></div><div>; This now only invalidates the .j part</div><div>%tok2 = call llvm.dbg.value(token %undef, %j, !Struct, !DIExpression(DW_OP_bit_piece(32, 32)))<br></div><div><br></div><div>In that case we would probably have to require that all DW_OP_bit_pieces in non-key-call expressions are a subrange of those in the associated key call.</div></div></div></div></div></blockquote><div><br></div></div></div><div>This way all non-key-call additional locations are describing alternative locations for (a subset of) the bits described the key-call location. Makes sense, and again would simplify the backend’s work.</div></div></div></blockquote><div><br></div><div>Yes, I think that's a reasonable change to the semantics, so let's make it so. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>One thing I’m wondering about is whether we couldn’t design a friendlier (assembler) syntax for the three different use-cases:</div><div>  %tok1 = call llvm.dbg.value(token %undef, %1, !var, !())</div>  %tok2 = call llvm.dbg.value(token %token, %2, !var, !())<div>  %tok3 = call llvm.dbg.value(token %tok1, %undef, !var, !())</div><div><br></div><div>Could be written as e.g.:</div><div><br></div><div><div>  %tok1 = call llvm.dbg.value.new(%1, !var, !())</div>  %tok2 = call llvm.dbg.value.add(token %token, %2, !var, !())<div>  %tok3 = call llvm.dbg.value.delete(token %tok1, !var, !())</div></div></div></blockquote><div><br></div><div>Yeah, I would be ok with that (and think it's a good idea). </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><span class="HOEnZb"><font color="#888888"><div>-- adrian</div></font></span></div></blockquote></div><br></div></div>