[PATCH] D16569: Emit line 0 line information for interesting 'orphan' instructions

Wed Jan 27 14:47:45 PST 2016

To quantify this, a quick experiment showed a line-0 directive occupied 5 bytes, of which 2 bytes were setting the column to zero.  Not setting the column reduces the size increase by 40%.

Good to know - does that include changing the file too? (On either side of the equation/data)
Though I expect some of the cost of these new line table entries includes changing it back to something else on the other side - in some cases I imagine it'll be changing it back to the same file/line, potentially. Though I suppose if we don't change the file, we'll save both the change, and the change back. Column probably changes anyway so it doesn't cost us anything on the change "back" perhaps.

Right, my accounting was incomplete, and my example used unrealistically small line numbers.  Let's try again being a little more analytical.

First off, I'm happy to make the simplifying assumption that column changes more-or-less every statement, and that we should accrue only one column-change per line-0 directive.  (Offhand I don't know how Clang decides to set the column numbers.)  Setting the column is a "standard" opcode, so occupies 1 byte plus the ULEB operand., which in this case will be 1 byte, for a total of 2 bytes.  This cost is going to accrue for every line-0 directive, unless we optimize it away.
Setting the file is also a standard opcode, again 1 byte plus the ULEB operand, which will usually be 1 byte (unless the file number > 127) so again assume 2 bytes. This will happen twice per line-0 directive in a scope outside actual file #1, which is less common but surely does happen.

Setting the line number is more 'fun.'  We'll simplify this to assume the line number is outside the line-range for special opcodes, so setting it to 0 and back requires standard opcodes.  This time it's a 1-byte opcode plus an SLEB operand, because you don't "set" the line, you "advance" the line. The max value you can encode as SLEB in 2 bytes is 8191, if I'm counting the bits correctly.  If we further assume most line numbers are in the range 127..8191 then setting the line number to 0 and back will require 3 bytes each.  In addition we'll need a 1-byte special opcode to advance the address and "emit" the line record.

So, assuming we fix the file-number problem (trivially, see my inline comment) and we're up past line 128, then a line-0 directive will cost:
2 bytes to set column=0
3 bytes to advance line to 0 [e.g. advance by -200, if we were at line 200]
1 byte special opcode to emit the record
3 bytes to advance line to 201 [or whatever]
and the rest of it would be like usual.

That adds up to 9 bytes per directive (usually), and if we optimize away the column number, we save 2 bytes, or 22% of the increase (not 40%, sigh).  But, I think, still worth doing.
--paulr

From: David Blaikie [mailto:dblaikie at gmail.com]
Sent: Wednesday, January 27, 2016 10:09 AM
To: reviews+D16569+public+6623e660a2ba7fa7 at reviews.llvm.org; Robinson, Paul
Cc: Frédéric Riss; Adrian Prantl; Eric Christopher; llvm-commits
Subject: Re: [PATCH] D16569: Emit line 0 line information for interesting 'orphan' instructions

On Wed, Jan 27, 2016 at 10:06 AM, Paul Robinson via llvm-commits <llvm-commits at lists.llvm.org<mailto:llvm-commits at lists.llvm.org>> wrote:
probinson added a comment.

In http://reviews.llvm.org/D16569#337412, @probinson wrote:

> Second, I'd hope that the column number is irrelevant and so we shouldn't bother explicitly setting it to zero. That's probably something that would have to be handled where the line-table gets encoded, rather than here, and so can be deferred to a follow-up.

To quantify this, a quick experiment showed a line-0 directive occupied 5 bytes, of which 2 bytes were setting the column to zero.  Not setting the column reduces the size increase by 40%.

Good to know - does that include changing the file too? (On either side of the equation/data)
Though I expect some of the cost of these new line table entries includes changing it back to something else on the other side - in some cases I imagine it'll be changing it back to the same file/line, potentially. Though I suppose if we don't change the file, we'll save both the change, and the change back. Column probably changes anyway so it doesn't cost us anything on the change "back" perhaps.

- Dave

http://reviews.llvm.org/D16569

_______________________________________________
llvm-commits mailing list
llvm-commits at lists.llvm.org<mailto:llvm-commits at lists.llvm.org>
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160127/c2412ba9/attachment.html>