public inbox for jit@gcc.gnu.org
 help / color / mirror / Atom feed
* Ravi updated to build against libgccjit 5.2.0
@ 2015-01-01  0:00 Dibyendu Majumdar
  2015-01-01  0:00 ` David Malcolm
  0 siblings, 1 reply; 4+ messages in thread
From: Dibyendu Majumdar @ 2015-01-01  0:00 UTC (permalink / raw)
  To: jit

Hi,

Since updating to libgccjit 5.2, Ravi's JIT compiler is working
without any patches. Performance is on par with the LLVM
implementation.

Presumably if I wanted to create a binary release including libgccjit
then I need to simply include the libgccjit shared library?

Thanks and Regards
Dibyendu

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Ravi updated to build against libgccjit 5.2.0
  2015-01-01  0:00 Ravi updated to build against libgccjit 5.2.0 Dibyendu Majumdar
@ 2015-01-01  0:00 ` David Malcolm
  2015-01-01  0:00   ` Dibyendu Majumdar
  0 siblings, 1 reply; 4+ messages in thread
From: David Malcolm @ 2015-01-01  0:00 UTC (permalink / raw)
  To: Dibyendu Majumdar; +Cc: jit

On Sat, 2015-07-25 at 11:27 +0100, Dibyendu Majumdar wrote:
> Hi,
> 
> Since updating to libgccjit 5.2, Ravi's JIT compiler is working
> without any patches. Performance is on par with the LLVM
> implementation.

Excellent.  Thanks for the heads-up.

I've taken the liberty of adding a link to Ravi to the wiki page:
  https://gcc.gnu.org/wiki/JIT
in the "Who's using this code?" section.

> Presumably if I wanted to create a binary release including libgccjit
> then I need to simply include the libgccjit shared library?

Ideally packages would eventually be available from OS vendors, but you
need 5.2 which is quite recent.

If you want to go down the bundling route, libgccjit.so by itself isn't
going to be enough: the shared library currently has a run-time
dependency on a driver binary that's built at the same time (see 
https://gcc.gnu.org/onlinedocs/jit/internals/index.html#envvar-PATH )
and maybe on a specific version of libgcc.  You may be able to get away
with just the driver binary.

So you may want to configure with an installation prefix
(--prefix=/somewhere-for-ravi-to-own) and "make install" to it when
building your release.

Alternatively, a nasty hack would be to hack up GCC_DRIVER_NAME in
jit/jit-playback.c to simply use the system "gcc" on the PATH, though
this assumes that that gcc is sufficiently compatible with the gcc 5
code in the libgccjit.so you built (e.g. the underlying toolchain can
cope with every opcode that it could generate).

Sorry that this is messy.   I'm hoping to embed the relevant code from
the driver in-process into libgccjit.so for gcc 6 (it's part of the
optimization patches I linked to in another post), which should simplify
this considerably.

Dave

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Ravi updated to build against libgccjit 5.2.0
  2015-01-01  0:00 ` David Malcolm
@ 2015-01-01  0:00   ` Dibyendu Majumdar
  2015-01-01  0:00     ` Dibyendu Majumdar
  0 siblings, 1 reply; 4+ messages in thread
From: Dibyendu Majumdar @ 2015-01-01  0:00 UTC (permalink / raw)
  To: David Malcolm; +Cc: jit

On 27 July 2015 at 21:47, David Malcolm <dmalcolm@redhat.com> wrote:
> I've taken the liberty of adding a link to Ravi to the wiki page:
>   https://gcc.gnu.org/wiki/JIT
> in the "Who's using this code?" section.

Ok thanks!

>> Presumably if I wanted to create a binary release including libgccjit
>> then I need to simply include the libgccjit shared library?
>
> Ideally packages would eventually be available from OS vendors, but you
> need 5.2 which is quite recent.
>
> If you want to go down the bundling route, libgccjit.so by itself isn't
> going to be enough: the shared library currently has a run-time
> dependency on a driver binary that's built at the same time (see
> https://gcc.gnu.org/onlinedocs/jit/internals/index.html#envvar-PATH )
> and maybe on a specific version of libgcc.  You may be able to get away
> with just the driver binary.
>
> So you may want to configure with an installation prefix
> (--prefix=/somewhere-for-ravi-to-own) and "make install" to it when
> building your release.
>
> Alternatively, a nasty hack would be to hack up GCC_DRIVER_NAME in
> jit/jit-playback.c to simply use the system "gcc" on the PATH, though
> this assumes that that gcc is sufficiently compatible with the gcc 5
> code in the libgccjit.so you built (e.g. the underlying toolchain can
> cope with every opcode that it could generate).
>
> Sorry that this is messy.   I'm hoping to embed the relevant code from
> the driver in-process into libgccjit.so for gcc 6 (it's part of the
> optimization patches I linked to in another post), which should simplify
> this considerably.
>

Yes, sounds messy. Maybe for now I will leave it to the user to build a binary.

Regards
Dibyendu

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Ravi updated to build against libgccjit 5.2.0
  2015-01-01  0:00   ` Dibyendu Majumdar
@ 2015-01-01  0:00     ` Dibyendu Majumdar
  0 siblings, 0 replies; 4+ messages in thread
From: Dibyendu Majumdar @ 2015-01-01  0:00 UTC (permalink / raw)
  To: David Malcolm; +Cc: jit

On 27 July 2015 at 22:46, Dibyendu Majumdar <mobile@majumdar.org.uk> wrote:
> On 27 July 2015 at 21:47, David Malcolm <dmalcolm@redhat.com> wrote:
>> I've taken the liberty of adding a link to Ravi to the wiki page:
>>   https://gcc.gnu.org/wiki/JIT
>> in the "Who's using this code?" section.
>
> Ok thanks!
>

BTW is Ravi the first real JIT implementation using libgccjit?

Happy to be the first!

Regards

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2015-07-28 22:27 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-01-01  0:00 Ravi updated to build against libgccjit 5.2.0 Dibyendu Majumdar
2015-01-01  0:00 ` David Malcolm
2015-01-01  0:00   ` Dibyendu Majumdar
2015-01-01  0:00     ` Dibyendu Majumdar

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).