[llvm] [DebugInfo][NVPTX] Adding support for `inlined_at` debug directive in NVPTX backend (PR #170239)

[David Blaikie via llvm-commits]

dwblaikie wrote:

> > > > I'm a bit confused by the implementation - at the start of the function, it scans for every inlined at location, then it checks if a given location has been found in that list and if it has, it emits it - but then removes these from the list?
> > > > It's possible for an inlinedAt location to appear more than once - it gets inlined, then some other code gets hoisted or sunk into the middle of the inlined location - what's meant to happen there?
> > > 
> > > 
> > > inlinedAt locations are added to the `DenseSet` to avoid emitting the same location multiple times, like the following `.locs` in this example. `.loc 1 31 5 // test.cu:31:5` `.loc 1 25 4, function_name $L__info_string0, inlined_at 1 31 5 // test.cu:25:4 `
> > 
> > 
> > Sorry, I'm still not quite following here - what would the output look like in this ^ example if the DenseSet weren't used?
> 
> [test.after.txt](https://github.com/user-attachments/files/24066076/test.after.txt) [test.No_DenseSet.txt](https://github.com/user-attachments/files/24066077/test.No_DenseSet.txt) Here's the output difference if DenseSet is not use- <img alt="image" width="1375" height="880" src="https://private-user-images.githubusercontent.com/17092969/524582881-99d9a20c-a390-4c15-9b17-b5d588aaddbf.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NjUzOTM3MzQsIm5iZiI6MTc2NTM5MzQzNCwicGF0aCI6Ii8xNzA5Mjk2OS81MjQ1ODI4ODEtOTlkOWEyMGMtYTM5MC00YzE1LTliMTctYjVkNTg4YWFkZGJmLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNTEyMTAlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjUxMjEwVDE5MDM1NFomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTJmOTE1ZGYxMTQxZDMwOTU4YTIyNTk0NWFkNmNjZjE5ZTgxZTQyYzU5MGRhMDUxYTNmY2ZjNzE4NGFjY2FmOWEmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0In0.bbgz6aMt7BNsRJMK8HwMr2rWZa10AXueLNqjUNgbbCs">
> 
> > That seems like a better approach to addressing that problem than having to add a new data structure/memory usage/extra scanning pass/etc.
> 
> Let me refactor the code and remove the scanning pass. I believe we can just keep track of already emitted locs.

I don't think "already emitted locs" is the relevant property/issue you're trying to address though, is it?

In the non-map/excess line directives output, you have this:
```
	.loc	1 31 5                          // test.cu:31:5
	.loc	1 25 4, function_name $L__info_string0, inlined_at 1 31 5 // test.cu:25:4
	.loc	1 11 5, function_name $L__info_string1, inlined_at 1 25 4 // test.cu:11:5
	shl.b32 	%r2, %r1, 1;
	.loc	1 31 5                          // test.cu:31:5
	.loc	1 25 4, function_name $L__info_string0, inlined_at 1 31 5 // test.cu:25:4
	.loc	1 12 5, function_name $L__info_string1, inlined_at 1 25 4 // test.cu:12:5
	add.s32 	%r3, %r2, %r1;
```
And then the "fixed version" is:
```
	.loc	1 31 5                          // test.cu:31:5
	.loc	1 25 4, function_name $L__info_string0, inlined_at 1 31 5 // test.cu:25:4
	.loc	1 11 5, function_name $L__info_string1, inlined_at 1 25 4 // test.cu:11:5
	shl.b32 	%r2, %r1, 1;
	.loc	1 12 5, function_name $L__info_string1, inlined_at 1 25 4 // test.cu:12:5
	add.s32 	%r3, %r2, %r1;
```
Which addresses the second sequence of `.loc` directives without instructions in between - but doesn't address the first one. Why is the second one suitable/necessary to change/remove, but not the first?

https://github.com/llvm/llvm-project/pull/170239