[llvm-dev] is_stmt and column numbers

[Roger Pack via llvm-dev]

It appears to me that from this:

https://iis-git.ee.ethz.ch/H2020-Compiler/llvm/commit/1d68fc5021ca8c704e21f171d98bb18eb396a7fa

That LLVM basically emits DWARF expressions where is_stmt is true only
"once per line". Is that still true? Is there an option to emit more
than one per line?

Thanks all.

-Roger Pack-

refs:
https://github.com/crystal-lang/crystal/pull/8499
https://github.com/crystal-lang/crystal/issues/8319
_______________________________________________
LLVM Developers mailing list
llvm...@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

[Robinson, Paul via llvm-dev]

> -----Original Message-----
> From: llvm-dev <llvm-dev...@lists.llvm.org> On Behalf Of Roger Pack
> via llvm-dev
> Sent: Tuesday, December 17, 2019 8:31 AM
> To: llvm-dev <llvm...@lists.llvm.org>
> Subject: [llvm-dev] is_stmt and column numbers
>
> It appears to me that from this:
>
> https://iis-git.ee.ethz.ch/H2020-
> Compiler/llvm/commit/1d68fc5021ca8c704e21f171d98bb18eb396a7fa
>
> That LLVM basically emits DWARF expressions where is_stmt is true only
> "once per line". Is that still true? Is there an option to emit more
> than one per line?
>
>
> Thanks all.
>
> -Roger Pack-
>
> refs:
> https://github.com/crystal-lang/crystal/pull/8499
> https://github.com/crystal-lang/crystal/issues/8319

is_stmt is based fairly strictly on "the line number changed" (while
ignoring line 0). This works reasonably well at -O0 and gets clunkier as
optimization level increases. I've never been happy about it, but have
never found the time to come up with something better. The optimizer has
been getting better at not introducing gratuitous line-number changes, if
that helps.

There is no option to make it work differently. We can (usually do) emit
column numbers, which gets you more line-table entries, although they are
not flagged with is_stmt. I know at least one debugger that gave up on
is_stmt "because it's not reliable."
--paulr

[Roger Pack via llvm-dev]

OK that makes sense. I've noticed that there'll be some DWARF
statements that set the line number to "0".

[0x0000048c] Special opcode 72: advance Address by 5 to 0x1000015b0
and Line by -3 to 0
[0x0000048d] Special opcode 78: advance Address by 5 to 0x1000015b5
and Line by 3 to 3

I assume this means some kind of internal processing? Anyway the
current work around crystal uses is to basically only accept DWARF
statements that have a positive line number [not sure if that's right
or not...], or if they're is_stmt then it accepts them :)
Thanks!

[Robinson, Paul via llvm-dev]

The DWARF spec says line 0 means there is no relevant source location.
Sometimes it means an optimization combined operations from multiple
source locations, and it would be misleading to pick one arbitrarily;
sometimes it means the instruction came from an "artificial" bit of
source, for example a default constructor in C++, that really has no
worthwhile source location.

I can't imagine a correct producer ever setting is_stmt for line 0.
--paulr