On Thu, Sep 06, 2018 at 02:46:28AM +0100, Ramsay Jones wrote: > > > On 06/09/18 01:52, Luc Van Oostenryck wrote: > > On Thu, Sep 06, 2018 at 01:00:11AM +0100, Ramsay Jones wrote: > >> On 05/09/18 23:38, Luc Van Oostenryck wrote: > >>> This will allow to reuse this code to generate valid IR > >>> in the case of a missing return statement. > >>> > >>> + add_return(ep, bb_return, expr->ctype, src); > >> > >> It does not matter here, but as a matter of interest, why pass > >> the entrypoint here, rather than the active bb? > > > > Indeed, ep in itself is not needed. I didn't noticed. > > It's mostly a matter of consistency: functions that will add > > an instruction generaly need the entrypoint because they may > > change the active BB. > > > >> Future plans? > > > > Hehe :) > > ;-) I was only enquiring about the add_return() function! > (Any future plans to use anything other than ep->active). I sort of supposed it was but it was more interesting so ;) To answer your real question: no, not that I can imagine. Unlike other parts, the linearization is essentially complete: * C won't have new language constructions * if new instructions will be added they won't impact linearization (I'm thinking about things like OP_ROL/OP_ROR or OP_BSWAP8/16/32). There is one expection though, it's for varags. I can't see other uses for add_return(). I prefer to leave 'ep' as argument since, to me, seeing this as the first argument means "this function need the current context/ will add instructions to the current BB", while seeing an explicit BB means "this function will add instructions to an arbitrary BB". -- Luc
