As there's something about branch prediction on the front page right now, "The slow winter" [0] is well worth a read too because
a) We should remember the magma people are waiting for our mistakes, and
b) the branches really did make a pact with an adversary, resulting in the spectre CPU vulnerabilities we know and love today.
(It really is worth a read; James Mickens is indeed a national treasure).
"If her hard disk is active for more than a second per hour, or if her CPU utilization goes above 4%, she either
has a computer virus, or she made the disastrous decision to
run a Java program"
Thank you for the rabbit hole, I look forward to the day when I see a scrawl on the wall saying “THE MAGMA PEOPLE ARE WAITING FOR OUR MISTAKES.” and being able to nod sagely whilst others are wondering what aliens wrote this.
> I'm referring to all the cases where the compiler obviously should know where the value is, yet the debugger somehow doesn't.
Soooommmee of this can be explained by the design decisions in the compiler not lending themselves to working well with debug-info, as explained here [0] (shamless plug), from about 3 minutes in there's an example of a scenario where a variable location has to be discarded out of conservative precaution (4:40 to 7:00), rather than because it's definitely been optimised out.
> I haven't looked at DWARF for ages. Can it describe the situation that a variable is valid (in some register) in the beginning of a function, but then goes "out of scope " in the middle of the function?
Yes, with DW_OP_entry_value used in location expressions to indicate that the variable value is in a certain location on entry to the function. However -- debuggers typically don't store all register values on entry to all functions, so usually the stack frame up needs to be instrumented with call site information indicating where the debugger can find longer-term stored copies of the arguments.
In TFA you can see that happening correctly wherever there's a "@entry" annotation from gdb for an argument, in some cases there isn't a longer-term copy of the value further up the stack, in which case the variable remains optimised out.
Assuming you're referring to the articles first example, I suspect optimised-out is the correct outcome in that situation. The program is stopped at the start of one function, and the author is looking one stack frame up at this code:
%rsi indeed hasn't been clobbered when the call executes, but it becomes liable to be clobbered during the execution of the callee. By the next instruction (at +54) there's no guarantee that %rsi contains the correct value, thus it's best reported as optimised out. The author is handily stopped at a point in time between the two instructions displayed above (in a lower stack frame), where the correct value happens to be in %rsi, but this is not guaranteed to be always true.
> they aren't (again, AFAIK) doing anything about it
Person slightly doing things to LLVM checking in -- the three points you list are compelling, because it's always going to be difficult to describe one program (source) in terms of a vastly different (optimised) program. Do you think there's mileage in showing the developer a partially optimised program [0] instead of trying to perfectly describe the source? It'd be easier to describe in debug-info, and possibly easier for developers to identify unexpected changes to the code they wrote.
[0] "Non-Transparent Debugging of Optimized Code", 1999
Possibly closer to the mark in terms of scripture is Ezekiel 38, which specifies that the Jews are to have returned/gathered from exile/dispersion and be living in peace ("unwalled cities") before an invasion/looting from the north. Of course, it only specifies the movement of peoples, not the political configuration of the land.
The same groups of people tend to apply that one to the Yom Kippur war, and treat it as already fulfilled. The thing about Jerusalem having to remain as a heavy stone is more what inspires them to defend it.
I've got a copy and still use it sometimes -- being able to immediately see nearby words (like "glad", "gladly", "gladness") is quite useful, which you'd miss just searching for "glad". Being able to see all uses on a hardcopy in a fixed position that doesn't scroll is helpful too, I find it harder to rationalise big lists when they're scrollable.
(I also use it to explain type checking to friends, given the number of times I've looked up a Hebrew word in the Greek dictionary, or vice versa).
To reinforce this, one of the statistics that the beeb have wheeled out is that in the most vulnerable group being vaccinated (in the UK), aged 80+, one in ten of them will die regardless of covid in the next year. Quoted from "How to vaccinate the world -- Vaccine Hesitancy" [0] from 12 minutes in to 15 minutes. (And because it's BBC sounds, for some reason it randomly skips episodes when I load the page).
The entire series is well worth a listen, data driven and statistics heavy.
> I'd like to learn more about this. Maybe contribute to the compiler and fix this issue.
You need to create a call to the `llvm.dbg.declare` intrinsic that connects the stack variable alloca to a DILocalVariable metadata node, and place the call after the stack variable alloca. The rest of LLVM will handle tracing the stack location through the compiler to the output, including the alloca being promoted.
(It really is worth a read; James Mickens is indeed a national treasure).
[0] https://scholar.harvard.edu/files/mickens/files/theslowwinte...