missing gcc_jit_context_new_rvalue_from_long_long etc....?

missing gcc_jit_context_new_rvalue_from_long_long etc....?

[Basile Starynkevitch]

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.

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)

Regards.

-- 
Basile Starynkevitch        http://starynkevitch.net/Basile/
France
 

Re: 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

Re: missing gcc_jit_context_new_rvalue_from_long_long etc....?

[Basile Starynkevitch]

On 07/15/2015 17:03, David Malcolm wrote:
> 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.


I just submitted the patch 
https://gcc.gnu.org/ml/gcc-patches/2015-07/msg01315.html for that.

Cheers.

-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***

cross-compilation & libgccjit

[Basile Starynkevitch]

On 07/15/2015 17:03, David Malcolm wrote that he is working on:
> (a) libgccjit: adding support for cross-compilation (perhaps with a 
> gcc_jit_target type).

If you do that, you really should change the name of your library. By 
definition Just-In-Time compilation is
with the host same as the target and forbids the idea of 
cross-compilation (which is always Ahead Of Time).

Perhaps your library should be renamed as libgccgeneratecode and sit in 
gcc/generate/

That name is not sexy, but I really believe that cross-compilation 
cannot be Just In Time by definition; so please don't call your library 
libgccjit (or anything containing JIT acronym) if it is not related to 
Just In Time compilation, see
https://en.wikipedia.org/wiki/Just-in-time_compilation


Please, please, don't name gccjit something which is not only for Just 
In Time. Find another name!

Cheers

-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***

Re: cross-compilation & libgccjit

[David Malcolm]

On Thu, 2015-07-16 at 11:10 +0200, Basile Starynkevitch wrote:
> On 07/15/2015 17:03, David Malcolm wrote that he is working on:
> > (a) libgccjit: adding support for cross-compilation (perhaps with a 
> > gcc_jit_target type).
> 
> If you do that, you really should change the name of your library. By 
> definition Just-In-Time compilation is
> with the host same as the target and forbids the idea of 
> cross-compilation (which is always Ahead Of Time).

I don't agree.  In my mind "Just-In-Time compilation" means doing the
compilation when you're about to execute the result, rather than a long
time in advance.

Consider a 3D videogame, running on an x86_64 computer, which compiles
OpenGL shader programs for a GPU.  You could have e.g.
  host == x86_64-linux
  target  == some radeon GPU, say
which is clearly cross-compilation, but the GPU code in question is
generated immediately before it is to be executed for the exact GPU
attached to the motherboard, and uploaded to it from main memory, rather
than being built ahead of time and packaged up as GPU binary with the
game CPU binary.

You might more reasonably complain about the ahead-of-time compilation
support provided by gcc_jit_context_compile_to_file, but that's
acknowledged in the docs as being not the primary scope of the library:
https://gcc.gnu.org/onlinedocs/jit/topics/compilation.html#ahead-of-time-compilation


> Perhaps your library should be renamed as libgccgeneratecode and sit in 
> gcc/generate/
> 
> That name is not sexy, but I really believe that cross-compilation 
> cannot be Just In Time by definition; so please don't call your library 
> libgccjit (or anything containing JIT acronym) if it is not related to 
> Just In Time compilation, see
> https://en.wikipedia.org/wiki/Just-in-time_compilation
> 
> 
> Please, please, don't name gccjit something which is not only for Just 
> In Time. Find another name!
> 
> Cheers
> 

Re: cross-compilation & libgccjit

[Basile Starynkevitch]

On 07/16/2015 17:30, David Malcolm wrote:
> On Thu, 2015-07-16 at 11:10 +0200, Basile Starynkevitch wrote:
>> On 07/15/2015 17:03, David Malcolm wrote that he is working on:
>>> (a) libgccjit: adding support for cross-compilation (perhaps with a
>>> gcc_jit_target type).
>> If you do that, you really should change the name of your library. By
>> definition Just-In-Time compilation is
>> with the host same as the target and forbids the idea of
>> cross-compilation (which is always Ahead Of Time).
> I don't agree.  In my mind "Just-In-Time compilation" means doing the
> compilation when you're about to execute the result, rather than a long
> time in advance.
>
> Consider a 3D videogame, running on an x86_64 computer, which compiles
> OpenGL shader programs for a GPU.  You could have e.g.
>    host == x86_64-linux
>    target  == some radeon GPU, say
> which is clearly cross-compilation, but the GPU code in question is
> generated immediately before it is to be executed for the exact GPU
> attached to the motherboard, and uploaded to it from main memory, rather
> than being built ahead of time and packaged up as GPU binary with the
> game CPU binary.

Ok, I'm convinced, sorry for the noise.

But then, please explain that in your documentation. It is really not 
obvious!

Cheers.


-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***

Re: missing gcc_jit_context_new_rvalue_from_long_long etc....?

[Basile Starynkevitch]

On 07/15/2015 17:03, David Malcolm wrote:
> Basile, you've made various API suggestions recently. Are you working 
> on (or hoping to work on) something specific that's using libgccjit?


Yes, the MELT monitor (a software which will interact with the MELT 
plugin, http://gcc-melt.org/ and keep *persistent* information about 
GCC+MELT compiled software, and give a Web interface to MELT)
I intend to publish to publish it (as GPLv3+ software) quickly and later 
merge it into MELT itself.
So perhaps one day we'll have something useful, using both MELT & GCCJIT

(FWIW, my github has -on july 15th 2015- an old prototype of the MELT 
monitor which is not the software I'm working on these days; in other 
words I am rewriting it and using GCCJIT)

I'm trying to release (but no promises at all, I might be asked to stop 
all) a MELT enhanced by its monitor within GCC 6.

Regards.

-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***