On 06/09/18 21:51, Luc Van Oostenryck wrote: > 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 ;) Indeed! > 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". Yep, I suspected it would be something like that. Sounds good to me ... :-D ATB, Ramsay Jones
