[PATCH] D28075: MergeFunctions: Preserve debug info in thunks, under option -mergefunc-preserve-debug-info

[Adrian Prantl via Phabricator via llvm-commits]

aprantl added a comment.

Thank you for working on this! Below are a couple of question to help my understanding:

> Under -mergefunc-preserve-debug-info MergeFunctions::writeThunk():>
>  Does not create a new function for the thunk.
> Retains the debug info (and associated instructions) in the entry block for the thunk's parameters. PS: -debug will display the algorithm at work.

So if I understand correctly this patch causes debug info for the function arguments to be preserved in the thunk for the merged function. Will the call sites of the merged function point to the thunk or directly to the shared implementation? Or is the. thunk only there to be invoked from the expression evaluator and other translation units?

> Creates debug-info for the call (to the "master-copy") made by the thunk and its return value.

So in the example in the testcase, if I'm stopped at  `y = dotSumB(c, a, b, 8);` in the debugger I would see:

  bt
  dotSumA() // confusing
  dotSumB() // the thunk with the debug info
  main()



> Does not mark the call made by the thunk as a tail-call, so that the backtrace indicates the execution flow at -O0.

- Is compiling with function merging and -O0 a combination used by anyone in practice?
- Wouldn't it be *better* to use a tail-call in the thunk, so we don't see the misleading debug info for `dotSumA()`?

(I think you gave the answer for this later on: it will get auto-converted to a tail call, but it never hurst to clarify).

Adrian



================
Comment at: lib/Transforms/IPO/MergeFunctions.cpp:234
+
+  /// Erase the instructions in PDIUnrelatedWL
+  void eraseInstsUnrelatedToPDI(std::vector<Instruction *> &PDIUnrelatedWL);
----------------
Nitpick: missing `.` (and remainder of sentence?) at the end.


================
Comment at: test/Transforms/MergeFunc/thunk-debugability.ll:441
+;     r[i] = p[i] * q[i];
+;   }
+;   for (i = 0, s = 0; i < size; i++)
----------------
Is all of this complexity necessary, or could the code be reduced further (e.g., but just doing the sum of p and eliminating q, etc...)?


https://reviews.llvm.org/D28075