Fix codeinstance mapping when using nested interpretation

[wsmoses]

see #754

[github-actions]

Your PR no longer requires formatting changes. Thank you for your contribution!

[codecov]

Codecov Report

❌ Patch coverage is 55.55556% with 20 lines in your changes missing coverage. Please review.
✅ Project coverage is 73.54%. Comparing base (e2d8505) to head (6fb410a).
⚠️ Report is 4 commits behind head on master.

Files with missing lines	Patch %	Lines
src/jlgen.jl	55.55%	20 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #755      +/-   ##
==========================================
- Coverage   74.75%   73.54%   -1.22%     
==========================================
  Files          24       24              
  Lines        3672     3791     +119     
==========================================
+ Hits         2745     2788      +43     
- Misses        927     1003      +76     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[maleadt]

Add a comment here.

[maleadt]

That said, all this complexity is there to be able to populate the compilation database. If we're fine with simply passing the entry-point CI to jl_get_function_id and extracting its name so that we can identify the entry point, we should be able to use the generated IR without having to correlated every mi/ci/function. And AFAIU none of the actual GPU back-ends uses the compilation database.

Can this be simplified on the Enzyme.jl end? Why does it need exact correlation between LLVM functions and their MI/CI?

[wsmoses]

No we need to retain the MI for each llvm function in order to determine where to apply custom rules, what types correspond to which LLVM args/instructions, among other things.