[PATCH] D58952: [llvm] Skip over empty line table entries.

[David Blaikie via Phabricator via llvm-commits]

dblaikie added a comment.

In D58952#1421508 <https://reviews.llvm.org/D58952#1421508>, @probinson wrote:

> In D58952#1420777 <https://reviews.llvm.org/D58952#1420777>, @dblaikie wrote:
>
> > In D58952#1420776 <https://reviews.llvm.org/D58952#1420776>, @probinson wrote:
> >
> > > > I'm not sure I follow this - the line table maps instructions to source locations. If there are no instructions there's nothing to map
> > >
> > > That's the intent. However, in practice it maps instruction *addresses* to source locations.
> >
> >
> > Well, in practice it's unspecified what it means - so we can look at this and come up with different interpretations. Mine is to interpret these as half open intervals - in which case [100, 100) is empty and you keep searching, then you find [100, 104) and that contains the address you're looking for.
>
>
> Understood, but if you're walking through the line-number program looking for address 100, and you find it as an exact match, on what grounds do you require the consumer to continue looking?


I don't require it - this is in unspecified territory. My interpretation is that the line table describes regions of instructions with half-open ranges.

>   The consumer does not know the interval is empty unless they keep looking past the exact match. The line-number program opcodes do not tell you about ranges, they only tell you about address-to-source mappings for individual addresses.

My understanding is that the source location applies to all instructions between two entries. (hence why there's an "end of sequence" entry - which describes the one-past-the-end address, not because it's saying anything about the source at that address (the range is open at that end), but because it's terminating the previous range)

If you were searching for 101 you'd keep going from 100 to find the 104 and then conclude that the entry at 100 applies to 100, 101 (what you care about), 102, and 103 (not 99, nor 104).

I'm suggesting it could come out quite naturally from an implementation scanning forward and looking at ranges, not to special case the exact match of 100 - and to scan for ranges, and test inclusion within those ranges.

> Now, if the consumer is fully parsing the line table, and (one assumes) converting to some other internal representation, then they'll find an empty range, and have to figure out what to do with it.  In that case, is throwing away the empty range really always the right thing to do?

My interpretation (not backed up by the spec - this is unspecified) is that yes, throwing it away is accurate, because the line table represents an address to source mapping and this entry describes a mapping from zero instructions.

>   Ignoring them for address-to-source mapping seems quite reasonable, but ignoring them for source-to-address mapping ("break on line 12") seems like unnecessarily throwing information away.

My interpretation is that there is no information here. LLVM said "the following instructions are at line 12" then emitted no instructions and went on to say "the following instructions are at line 15" and then emitted instructions - I think it'd be inappropriate (I can't say incorrect, because the spec doesn't say) to conclude that the instructions on line 15 have any relationship to line 12.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D58952