Provide a switch option 'newscope' to determine whether different Bas…

[RonxBulld]

Provide a switch option 'newscope' to determine whether different BasicBlocks of the same Subprogram have different DIScopes.

[vaivaswatha]

Sorry I somehow missed the notification for this PR. It looks fine to me, but I'm curious as to how this makes a difference. Can you provide a small example for understanding? (here in the PR, not in the code).

Thank you for the contribution.

[RonxBulld]

In previous versions of the code, each unseen BasicBlock was assigned a Scope, which caused some variables to be invisible in complex control flow. The modified program allows assigning a Scope to each Subprogram, so different BasicBlocks share the same Scope and variables across blocks will be seen.

Sorry I somehow missed the notification for this PR. It looks fine to me, but I'm curious as to how this makes a difference. Can you provide a small example for understanding? (here in the PR, not in the code).

Thank you for the contribution.

[vaivaswatha]

In previous versions of the code, each unseen BasicBlock was assigned a Scope, which caused some variables to be invisible in complex control flow. The modified program allows assigning a Scope to each Subprogram, so different BasicBlocks share the same Scope and variables across blocks will be seen.

Sorry I somehow missed the notification for this PR. It looks fine to me, but I'm curious as to how this makes a difference. Can you provide a small example for understanding? (here in the PR, not in the code).
Thank you for the contribution.

Do you have an example of such a complex control flow? I'm curious to see how this happens.

[RonxBulld]

In your example, without using the new feature, when the program runs to:
ret i32 0
, execute the gdb command:
p tmp17
will produce the error:
No symbol "tmp17" in current context..
But if you use the new feature, you can see the output:
$1 = 154 '\232'.

[vaivaswatha]

In your example, without using the new feature, when the program runs to: ret i32 0 , execute the gdb command: p tmp17 will produce the error: No symbol "tmp17" in current context.. But if you use the new feature, you can see the output: $1 = 154 '\232'.

Thank you. That helped.

This doesn't seem correct to me though.

1. At ret i32 0, tmp17 is indeed not in scope, so why should it be accessible there?
2. Assuming that that's just being "user friendly", how is always returning the parent scope going to help? for example if tmp17 were in a 2-depth (or more) scope, then we'd still not see it in scope.
3. Given (2), the name BBAlwaysNewScope doesn't seem right.

[RonxBulld]

In your example, without using the new feature, when the program runs to: ret i32 0 , execute the gdb command: p tmp17 will produce the error: No symbol "tmp17" in current context.. But if you use the new feature, you can see the output: $1 = 154 '\232'.

Thank you. That helped.

This doesn't seem correct to me though.

1. At `ret i32 0`, `tmp17` is indeed not in scope, so why should it be accessible there?

2. Assuming that that's just being "user friendly", how is always returning the parent scope going to help? for example if `tmp17` were in a 2-depth (or more) scope, then we'd still not see it in scope.

3. Given (2), the name `BBAlwaysNewScope` doesn't seem right.

Consider this example:
int main() {
int a = 123;
if (a == 123)
{
int b = a;
a = b;
}
return 0;
}
LLVM IR does not have an explicit hierarchy between basic blocks, and if this feature is not introduced, inside a conditional branch block, information in its parent hierarchy will not be visible.

[vaivaswatha]

In your example, without using the new feature, when the program runs to: ret i32 0 , execute the gdb command: p tmp17 will produce the error: No symbol "tmp17" in current context.. But if you use the new feature, you can see the output: $1 = 154 '\232'.

Thank you. That helped.
This doesn't seem correct to me though.

1. At `ret i32 0`, `tmp17` is indeed not in scope, so why should it be accessible there?

2. Assuming that that's just being "user friendly", how is always returning the parent scope going to help? for example if `tmp17` were in a 2-depth (or more) scope, then we'd still not see it in scope.

3. Given (2), the name `BBAlwaysNewScope` doesn't seem right.

Consider this example: int main() { int a = 123; if (a == 123) { int b = a; a = b; } return 0; } LLVM IR does not have an explicit hierarchy between basic blocks, and if this feature is not introduced, inside a conditional branch block, information in its parent hierarchy will not be visible.

Sorry that I'm being persistent, but I still don't understand. Can you post an LLVM-IR example? (because this pass is supposed to add debug information to LLVM-IR as if that were the source itself), and mention which variable should've been "printable" but is not, and at which line.