[PATCH 12/27] New file: gcc/jit/jit-recording.h

[Jeff Law]

On 11/04/14 09:12, David Malcolm wrote:
>> So give the complexities in interfacing with the guts of GCC, would it
>> make sense to expose the validate method?
>
> Most of the error-checking in the API happens in the API calls in
> libgccjit.c, testing that the individual pieces are sane.
>
> The validate method tests the things that can only be verified "as a
> whole", when the context is about to be compiled: are there unreachable
> blocks?  is every block terminated?  etc
>
> I can't quite see why client code might want to perform the latter kind
> of validation without actually doing a compile, so I don't plan to
> expose this at this time.  It's trivial to do so if someone needs it.
Yea, I saw all the border checking -- I was thinking mostly about things 
that require larger context.  In particular I was thinking block 
contents, the cfg and such.

Thinking about how I tend to work and might use this, I'd be likely to 
start building up statements/blocks and want to verify them without 
going all the way through compilation.  But that may be an artifact of 
living in a world where we have many points (between each pass) where a 
verification step for key data structures is useful.

I certainly don't see it as a blocking issue, just wanted to raise the 
possibility that exposing the verification step in the ABI might be 
useful.  If you don't want to do that right now, I can live with it.

>
> I think I was trying to avoid std::string for some reason, but I'm not
> quite sure why, perhaps out of a misremembered idea that libstdc++ was
> verboten (I currently use std:: in one place, in jit-playback.h, where a
> playback::context has a:
>    vec<std::pair<tree, location *> > m_cached_locations;
> ).
I can't see any reason why we wouldn't use basic capabilities of the C++ 
runtime system.  To use an example we both know and understand, 
switching EXPR_LIST to a forward_list would be something I would look 
favorably upon simply because everyone doing C++ knows what a 
forward_list is, it's proprties, strenghts & weaknesses.  Only GCC 
junkies happen to know that EXPR_LIST is just a hand-rolled forward list :-)


>
> In any case recording::string is an implementation detail hidden within
> the library.  It is a recording::memento and hence has the same lifetime
> as the recording::context.  I can't think of a reason off the top of my
> head why a std::string wouldn't work instead, but the existing code
> works, and has been through a fair amount of debugging.
How about as a follow-up?  I don't see this as being big enough to 
warrant blocking the work.

jeff