https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78685

--- Comment #44 from rguenther at suse dot de <rguenther at suse dot de> ---
On Thu, 12 Mar 2026, matthias at urlichs dot de wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78685
> 
> --- Comment #43 from Matthias Urlichs <matthias at urlichs dot de> ---
> On 12.03.26 09:51, rguenther at suse dot de wrote:
> > But making all variables
> > live until end of scope defeats the goal of having optimized code.
> 
> True; however, maybe we can spend some effort on adapting the 
> optimization rules here. My pet peeve here is that debuggable optimized 
> code should free no-longer-used variables at the start of the next 
> statement, instead of at the end of the current one.

The constraint here is what is reasonably implementable.  Even keeping
variables live at the end of scope would require hacks or new IL
features.  The current knob we have is mostly enabling/disabling
optimization passes, or disabling parts of a pass with adding
if (optimize_debug) guards.  Hacks usually involve emitting additional
inline assembler statements as we mostly do not optimize those.

> That way, I can set a conditional breakpoint on the result of a function 
> call (i.e. on the next line) and would still be able to examine the 
> call's arguments.

It might be comparatively cheaper to spill arguments not in memory
at the caller to the stack there.  For this particular issue, that is.

Reply via email to