missing gcc_jit_context_new_rvalue_from_long_long etc....?

[David Malcolm]

On Wed, 2015-07-15 at 10:25 +0200, Basile Starynkevitch wrote:
> Hello all,
> 
> It looks like we are missing functions to create various rvalues from
> various numerical types, e.g.
> 
>    gcc_jit_rvalue * 
>    gcc_jit_context_new_rvalue_from_long_long(gcc_jit_context *ctxt, 
>                                              gcc_jit_type *numeric_type, 
>                                              
>    gcc_jit_rvalue *
>    gcc_jit_context_new_rvalue_from_int64(gcc_jit_context *ctxt,
>                                              gcc_jit_type *numeric_type,
>                                              int64_t value);
> 
>    gcc_jit_rvalue *
>    gcc_jit_context_new_rvalue_from_uint64(gcc_jit_context *ctxt,
>                                              gcc_jit_type *numeric_type,
>                                              uint64_t value);
> 
> 
>    gcc_jit_rvalue *
>    gcc_jit_context_new_rvalue_from_long_double(gcc_jit_context *ctxt,
>                                              gcc_jit_type *numeric_type,
>                                              long double value);
> 
> and many more (int128_t & intptr_t perhaps, and all the types defined
> by the C99 standard in <stdint.h>?).
> 
> On x86-64/Linux this does not matters much, because `long` are 64 bits already.
> On some 32 bits architecture (ia32 a.k.a. 32 bits x86, or ARM) it might matter more.

If this is an issue, it's fixable; internally the library uses templates
to represent the different host types.

See r219401 (aka git commit feea5a1ffb846e07cc669e37fbb89991114bc589)
for the relevant patch.

So we could add entrypoints for the biggest host types, if needed, (with
signed/unsigned variants as appropriate) using an approach like that.


> Perhaps we might want to parse some constants from a string, and have some
> 
>    gcc_jit_rvalue *
>    gcc_jit_context_new_rvalue_from_parsed_string(gcc_jit_context *ctxt,
>                                              gcc_jit_type *numeric_type,
>                                              const char*string);
> 
> where string could be something like "0x123456789abcdef0" or "007"
> (i.e. C-like lexical conventions)

I'd rather that the API provided specific entrypoints for specific host
types, ideally without needing string parsing (the latter would likely
be slow, though maybe it's useful to have in of itself).


There's an opportunity-cost associated with each thing we could work on.
FWIW I'm hoping to spend my remaining GCC 6 "stage 1" development time
on a couple of big items:

  (a) libgccjit: adding support for cross-compilation (perhaps with a
gcc_jit_target type).

  (b) gcc in general: source-location ranges in diagnostics, allowing
for something like:
https://dmalcolm.fedorapeople.org/gcc/2015-03-09/multiline-rich-location-02.html

I'm attempting to focus on (b) right now.

I implemented switch statements since there was a clear use for it for
someone implementing a JVM (which I see as a key use-case), and I've
done a lot of jit work lately to support the work Dibyendu is doing on
Ravi, since it's an example of someone other than me using libgccjit
(and hence he's running into issues I didn't think of).

Basile, you've made various API suggestions recently.  Are you working
on (or hoping to work on) something specific that's using libgccjit?  Or
is this more out of a "trying to think ahead to support the project"
motivation?  I'm much more interested in the former than the latter.

Alternatively, is this something you'd be interested in providing a
patch for? (see the commit referenced above for some hints on how to do
it)
[I'd love to have other people providing non-trivial patches]

Thanks
Dave