On 10/19/2017 05:01 AM, Richard Biener wrote: > On Sat, Sep 30, 2017 at 11:08 AM, Alexandre Oliva <aol...@redhat.com> wrote: >> This API change will enable final_start_function() to "consume" >> initial insns, and choose the first insn to be passed to final(). >> >> Many ports call final_start_function() and final() when creating >> thunks and whatnot, so they needed adjusting. > > But for MI thunks (and whatnot) there's no debug info. So why do we care? > Most of them ask for sth very low-level. True.
> > That is, almost all the time the sequence is final_start_function immediately > followed by a call to final. So isn't better refactoring the answer here? > Some ports only call final_start_function and never final for their thunks > for example. > > That said, what do we lose when you do not adjust these things? Good question. And more generally when do we want to be able to do something sensible of this kind of glue code and what *is* sensible to do here? > > After all final () does more stuff than calling final_scan_insn on all > insns but you only do that for those you handle in final_start_function. > > It seems to me that the current split between start/final/end is too > artificial and that the few "raw" building blocks that backends maybe > need should be factored out for them? Perhaps. I think we'd need to see this fleshed out a bit more. > > That said, it looks like an ugly "layering" violation you are introducing. > > But of course I don't know history or details around this part of the > compiler... > > That said, all ports invoking final () invoke it in the > start/final/end sequence. > > spu, s390, rs6000 (and thus powerpcspe), pa, nds32, i386, cris, arm > invoke final_start_function and not final in the next 3 lines. They all > invoke final_end_function but not final inbetween (all invokers of final > do the 3-line dance). For the PA, thunks are emitted as pure assembly without generating RTL for the thunk. There is no RTL to pass to final (or if there is RTL lying around, it's probably not the thunk). There's a few things in the thunk that I don't think we can represent in RTL, though obviously a few UNSPECs could do the trick. One question in my mind is whether or not we can reasonably expect Alex to do that work, then the analysis on the other ports and fix them as well. Jeff
