On Mon, 2014-11-03 at 15:03 -0700, Jeff Law wrote:
> On 10/31/14 11:02, David Malcolm wrote:
> > Implementation of the gcc::jit::recording internal API, so that
> > libgccjit.c can record the calls that are made to the public API, for
> > later playback by the dummy frontend.
> >
> > gcc/jit/
> > * jit-recording.c: New.
> Cursory review since it's the JIT implementation directory which you'll
> likely end up owning...
>
>
> > +
> > +/* Assuming that this block has been terminated, get the number of
> > + successor blocks, which will be 0, 1 or 2, for return, unconditional
> > + jump, and conditional jump respectively.
> > + NEXT1 and NEXT2 must be non-NULL. The first successor block (if any)
> > + is written to NEXT1, and the second (if any) to NEXT2.
> > +
> > + Used when validating functions, and when dumping dot representations
> > + of them. */
> So presumably no multi-way branches yet? Might be better to build the
> API in such a way that it handles multi-way branches from the get-go
> rather than retrofitting later. Your call.
This is an internal API. If the external API needs to support building
switch statements from client code maybe with something like this:
extern void
gcc_jit_block_end_with_switch (gcc_jit_block *block,
gcc_jit_location *loc,
gcc_jit_rvalue *expr,
int num_cases,
gcc_jit_rvalue **case_values,
gcc_jit_block **case_blocks,
gcc_jit_block *default_block);
then this internal API would obviously need to change, maybe becoming:
virtual int get_num_successor_blocks () const;
virtual block *get_successor_block (int index) const;
but that won't affect the public API.
That said it's not clear to me that we do need to support switch
statements; no JIT implementation I've seen has needed them
(I put them in the "Probably not needed" section of TODO.rst).
> Otherwise I don't see anything objectionable. OK for the trunk.
Thanks
Dave
