Taichi: [ir] Annotate each IR with file:lineno:[line content]?

[k-ye]

Concisely describe the proposed feature

Much like tb info, It will be great that when printing the IRs, they are annotated with file:lineno + actual line content. E.g.

  <i32 x1> $0 = const [680]  # foo.py:12, x[i] = *
  <i32 x1> $1 = const [680]
  <i32 x1> $2 = const [1]
  <i32 x1> $3 = const [1]    # foo.py:13, y[i] = *
  <i32 x1> $4 = const [-1]
  <i32 x1> $5 = const [0]
  <i32 x1> $6 = const [0]
  <i32 x1> $7 = alloca       # foo.py:14, x[i] += y[i]
  <i32 x1> $8 = const [0]
  <i32 x1> $9 = const [1048576]
  ...

Currently when looking at IR, I have no idea where they come from...

Describe the solution you'd like (if any)

• Add a new field to IRNode, something like file_lineno_content. Maybe it's fine to only have lineno? Since most of the time we use Taichi in a single file, and we can always find out the line content from the lineno
• When doing transformations, make sure to propgate this info to the new IR stmts that will be inserted. This way even after optimizations, we at least have an idea of which Python code lead to them.
• Since many IR nodes will share the same file:lineno info, it's probably better to do string interning, and store pointers to these linenos in each IR node?

Additional comments
Add any other context or screenshots about the feature request here.

[archibate]

This is great for debugging IR, thank for purposing this, I've been wondering this for a long time. This is also a great step towards CHI.
But please note that we have optimization passes, IRNode's can easily get out-of-order or one-became-multiple, how do we track line infomation then?

1. disable optimization when debugging with lineinfo.
2. We preserve lineinfo for each IRNode, even if it's out-of-order or multiple.

[k-ye]

IRNode's can easily get out-of-order or one-became-multiple, how do we track line information then?

Exactly.. I think your point 2 basically aligns with what I have in mind:

When doing transformations, make sure to propagate this info to the new IR stmts that will be inserted.

My reasoning is that even it's out of order, at least it's good for us to know which Py source code leads to these IRs.

---

However, note that we might want to do this after #925 ? Otherwise we would have to throw away the works done for the Frontend stmts.

[archibate]

My reasoning is that even it's out of order, at least it's good for us to know which Py source code leads to these IRs.

The problem is, 1 IR at the output can be combined of 2 IRs at the input. e.g.:

x[None] += 2  # L22
x[None] += 3  # L23
x[None] += 1  # L24

Exactly.. I think your point 2 basically aligns with what I have in mind:

So we will get:

<i32x1> $2 = const [6]          # foo.py:L22, L23, L24
<i32x1> $3 = atomicAdd($1, $2)  # foo.py:L22, L23, L24

?

[k-ye]

Good point.. TBH I didn't give it too much thought. Maybe we need to look into DWARF and objdump to figure out a robust way for doing this, which seems a total overkill to me.

Alternatively, how about we provider another printer, which interleaves Py and IRs:

x[None] += 2  # L22
x[None] += 3  # L23
x[None] += 1  # L24

  <i32x1> $2 = const [6]
  <i32x1> $3 = atomicAdd($1, $2)
---
more python

  more IR
---
...

[yuanming-hu]

I would say this is definitely something we should do to improve the developer experience. But before this, maybe we should first improve the user experience: sometimes even syntax errors/warnings (during type checking) do not have an informative line number...

[k-ye]

FYI, I think objdump interleaves the source code and assemblies, e.g.

Disassembly of section __TEXT,__text:

0000000100000f10 __Z8do_stuffi:
; {
100000f10: 55                           pushq   %rbp
100000f11: 48 89 e5                     movq    %rsp, %rbp
100000f14: 48 83 ec 10                  subq    $16, %rsp
100000f18: 89 7d fc                     movl    %edi, -4(%rbp)
;     int my_local = my_arg + 2;
100000f1b: 8b 45 fc                     movl    -4(%rbp), %eax
100000f1e: 83 c0 02                     addl    $2, %eax
100000f21: 89 45 f8                     movl    %eax, -8(%rbp)
;     for (i = 0; i < my_local; ++i)
100000f24: c7 45 f4 00 00 00 00         movl    $0, -12(%rbp)
100000f2b: 8b 45 f4                     movl    -12(%rbp), %eax
100000f2e: 3b 45 f8                     cmpl    -8(%rbp), %eax
100000f31: 0f 8d 1f 00 00 00            jge 31 <__Z8do_stuffi+0x46>
;         printf("i = %d\n", i);
100000f37: 8b 75 f4                     movl    -12(%rbp), %esi
100000f3a: 48 8d 3d 61 00 00 00         leaq    97(%rip), %rdi
100000f41: b0 00                        movb    $0, %al
100000f43: e8 3a 00 00 00               callq   58 <dyld_stub_binder+0x100000f82>
;     for (i = 0; i < my_local; ++i)
100000f48: 8b 45 f4                     movl    -12(%rbp), %eax
100000f4b: 83 c0 01                     addl    $1, %eax
100000f4e: 89 45 f4                     movl    %eax, -12(%rbp)
100000f51: e9 d5 ff ff ff               jmp -43 <__Z8do_stuffi+0x1b>
; }
100000f56: 48 83 c4 10                  addq    $16, %rsp
100000f5a: 5d                           popq    %rbp
100000f5b: c3                           retq
100000f5c: 0f 1f 40 00                  nopl    (%rax)

See also https://eli.thegreenplace.net/2011/02/07/how-debuggers-work-part-3-debugging-information

[archibate]

I guess a easy-to-start one is to print the kernel name in irpass::print like:

- kernel {
+ kernel foo {

[k-ye]

Agree, i think that also helps the IR readability as a start..