8 ms·

Glad you enjoyed it. For clang users things would get a lot better if someone just fixed a lot of clang bugs. Omniscient debugging creates new opportunities t

by roca 7y ago

Glad you enjoyed it. For clang users things would get a lot better if someone just fixed a lot of clang bugs. Omniscient debugging creates new opportunities to overcome the impact of optimizations. E.g. are you trying to display the value of a variable after its live range ended? No problem, look back in time to when it was live. However, in many cases we need extensions to debuginfo to take advantage of that; e.g. DWARF can't express the difference between "variable outside live range, but has not been modified" and "we don't know where it is". If we had a debug build and an opt build of the same program then there are some mad-science approaches that would be fun to try. So I actually think the perf/debuggability tradeoff is not fundamental and with the right resources we could mostly make it go away.

pizlonator 7y ago
JSC tries to go into the tricks you describe for the purpose of optimizing OSR exit. It’s really hard. There is a register pressure overhead from situations where the program thought a thing was live but really at that program point some of the necessary inputs to the value you’re trying to recover (and the value itself) would have been trashed by regalloc if it wasn’t for the need to be able to rematerialize that value. That translates into register pressure and you can feel it even on forgiving platforms like arm64. I believe that this overhead in conditions where the codegen is otherwise behaving well is around 5%. So not terrible, but that’s my call of the price relative to -O3 or whatever.
- roca 7y ago
  Perhaps I wasn't clear. None of things I mentioned would entail changing the generated code in any way. In the comment about omniscience, here's an example of what I'm proposing: -- Debuginfo says variable 'x' is in register R1 in the PC range 0-10 -- At 10, R1 is set to something unrelated -- Debuginfo says in the PC range 10-20, 'x' is equal to its last live value (i.e. its value at PC=10) Pernosco would evaluate the value of 'x' at PC=15 by actually reconstructing the value in R1 at PC=10, using the omniscient database we already have. Of course DWARF can't currently express this, because normal debuggers can't make use of it. Even in rr it would be quite expensive to compute. If you're familiar with DW_OP_entry_value, it's a bit like that. That's a way for DWARF to say "the value of this variable (e.g. a parameter) is equal to the value of this subexpression (usually a register) on entry to the function", which regular debuggers can often obtain using stack unwinding. Pernosco doesn't do the unwinding, instead it (logically) warps back in time to the point where the function was called and evaluates the subexpression in that context.
  - pizlonator 7y ago
    Gotcha. I get what you’re saying now: you just replay and it’s all good.

by roca 7y ago

pizlonator 7y ago

JSC tries to go into the tricks you describe for the purpose of optimizing OSR exit. It’s really hard. There is a register pressure overhead from situations where the program thought a thing was live but really at that program point some of the necessary inputs to the value you’re trying to recover (and the value itself) would have been trashed by regalloc if it wasn’t for the need to be able to rematerialize that value. That translates into register pressure and you can feel it even on forgiving platforms like arm64. I believe that this overhead in conditions where the codegen is otherwise behaving well is around 5%. So not terrible, but that’s my call of the price relative to -O3 or whatever.

roca 7y ago
Perhaps I wasn't clear. None of things I mentioned would entail changing the generated code in any way. In the comment about omniscience, here's an example of what I'm proposing: -- Debuginfo says variable 'x' is in register R1 in the PC range 0-10 -- At 10, R1 is set to something unrelated -- Debuginfo says in the PC range 10-20, 'x' is equal to its last live value (i.e. its value at PC=10) Pernosco would evaluate the value of 'x' at PC=15 by actually reconstructing the value in R1 at PC=10, using the omniscient database we already have. Of course DWARF can't currently express this, because normal debuggers can't make use of it. Even in rr it would be quite expensive to compute. If you're familiar with DW_OP_entry_value, it's a bit like that. That's a way for DWARF to say "the value of this variable (e.g. a parameter) is equal to the value of this subexpression (usually a register) on entry to the function", which regular debuggers can often obtain using stack unwinding. Pernosco doesn't do the unwinding, instead it (logically) warps back in time to the point where the function was called and evaluates the subexpression in that context.
- pizlonator 7y ago
  Gotcha. I get what you’re saying now: you just replay and it’s all good.