https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90348
--- Comment #18 from Michael Matz <matz at gcc dot gnu.org> --- (In reply to Alexander Monakov from comment #17) > I think part of the problem is trying to make "deaths" explicit via CLOBBERs > without making "births" also explicit in the IR. Yes, that's basically the crux (or rather, that our births (first mention of a decl name) don't conflict with address-taking or access), and without changing this we're bound to heap hacks onto hacks to make it all work. So, ideally we'd represent the births of local decls as well (i.e. "allocate" them), represent all accesses indirectly via pointers, and "free" them at deaths. Optionally, very late in the pipeline, we can rewrite alloc/free pairs whose pointers don't escape into direct accesses to decls again (not sure if that's worthwhile at all; the 'free/alloc' statements would be virtual anyway, and we would handle only decls that must lie in memory this way). With that we'd have to amend some optimizations nevertheless, as those alloc/free pairs would hinder optimizations (no moving of instructions accessing the locals over them), so they would have to be moved sometimes in order to allow them (if deemed profitable).
