Andrea Corallo <andrea.cora...@arm.com> writes: >> It occurred to me that the entrypoint is combining two things: >> - creating a global char[] >> - creating an initializer for that global >> >> which got me wondering if we should instead have a way to add >> initializers for globals. >> >> My first thought was something like: >> >> gcc_jit_context_new_global_with_initializer >> >> which would be like gcc_jit_context_new_global but would have an >> additional gcc_jit_rvalue *init_value param? >> The global would have to be of kind GCC_JIT_GLOBAL_EXPORTED or >> GCC_JIT_GLOBAL_INTERNAL, not GCC_JIT_GLOBAL_IMPORTED. >> >> Alternatively, maybe it would be better to have >> >> gcc_jit_global_set_initializer (gcc_jit_lvalue *global, >> gcc_jit_rvalue *init_val); >> >> to make the API more flexible. >> >> But even if we had this, we'd still need some way to create the rvalue >> for that initial value. Also, maybe there ought to be a distinction >> between rvalues that can vary at runtime vs those that can be computed >> at compile-time (and are thus suitable for use in static >> initialization). >> >> I suspect you may have gone through the same thought process and come >> up with a simpler approach. (I'm mostly just "thinking out loud" >> here, sorry if it isn't very coherent). > > Yes I had kind of similar thoughs. > > Ideally would be good to have a generic solution, the complication is > that as you mentioned not every rvalue is suitable for initializing > every global, but rather the opposite. My fear was that the space to be > covered would be non trivial for a robust solution in this case. > > Also I believe we currently have no way to express in libgccjit rvalues > an array with some content, so how to use this as initializer? Perhaps > also we should have a new type gcc_jit_initializer? > > On the other hand I thought that for simple things like integers the > problem is tipically already solved with an assignment in some init code > (infact I think so far nobody complained) while the real standing > limitation is for blobs (perhaps I'm wrong). And in the end if you can > stuff some data in, you can use it later for any scope. > > Another "hybrid" solution would be to have specific entry point for each > type of the subset we want to allow for static initialization. This way > we still control the creation of the initializer internally so it's > safe. In this view this blob entry point would be just one of these > (probably with a different name like > 'gcc_jit_context_new_glob_init_char_array'). >
Hi Dave, wanted to ask if you formed an opinion about the patch and/or more in general the problem of static initialize data. Thanks Andrea
