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).
However, ...
> Well ... 3 years ago I had a bit free time and a patch that
> was waiting since 12 or 13 years. I said to myself "wouldn't
> it be nice if I would clean it up a little bit and upstream it?"
> And then when cleaning it I found a few bugs in the official
> code, then there was some patches from other people that was
> waiting a review since months (_Static_assert() & the constness
> rework) and voilà. Now I have about 180 topics/branches that
> are pending.
>
> My short term plan is to fix all problems related to linearization
> & SSA (the classic SSA is now in (my) master, I'm busy with the
> current series to fix some problems with the phi-nodes from
> linearization), the next step will be to make simplify_loads()
> generate valid SSA. A longer term will be to write an simulator
> for the IR (which won't be hard but need stuff put in place first,
> like correct SSA).
>
> I also have this series 'codegen' that can be used to generate
> code for ARM, ARM64 & RISC-V (it's still crude and lack
> register allocation but it's quite cool). And there is tons
> of stuff to do on optimization.
>
> There is also an interesting series to allow __bitwise
> for enums (which is not active for the moment because
> it impacts quite a bit of the current kernel code and there is
> a few choices that need to be done).
> Having good doc is also a goal ...
> It would also be good to be a bit more attentive to the needs
> on the kernel side.
... good to know.
> Oh yes, it it would be good if the patch 551b85c8a
> ("sparse: add -Wpointer-arith flag to toggle sizeof(void) warnings")
> could be in the official tree *long sigh*.
:-D
ATB,
Ramsay Jones
