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
