Andrea Corallo <andrea.cora...@arm.com> writes: > 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
Ping
