Simple install hook

Added install hook:

/opt/gjit/bin/gcc -g -O2 -Wall t.c -o test -I/opt/gjit/include
-lgccjit -L/opt/gjit/lib

Compiles the helloworld examples correctly and it runs instead of
pointing to my gcc build dir. Am working on getting more involved with
this and started:

https://github.com/redbrain/spy

Its only just starting to parse stuff but a kind of C/Python kind of
language using gcc as a JIT might be interesting kind of dynamic
language for C that can call C libs safely and easily is the idea.
Mostly just so i can see where to help out in the jit front-end.

Was also considering some kind of libopcodes work to assemble the code
in memory instead of creating a .so in /tmp. Not sure if i know what i
am doing enough there but it might be more elegant for stuff using
this front-end.

Am so impressed how well this works.

Thanks David.

On Tue, 2014-02-11 at 16:51 +0000, Philip Herron wrote:
[adding the jit@gcc.gnu.org ML to the CC]

> Added install hook:

Thanks!

I don't know that this is needed for a 3-line patch, but have you done
the copyright assignment paperwork for GCC contribution?  (I hope to
merge my branch into gcc trunk at some point).  [Also, I'd love to have
more, larger, patches from you for the jit branch!]

> /opt/gjit/bin/gcc -g -O2 -Wall t.c -o test -I/opt/gjit/include
> -lgccjit -L/opt/gjit/lib
> 
> Compiles the helloworld examples correctly and it runs instead of
> pointing to my gcc build dir. Am working on getting more involved with
> this and started:
> 
> https://github.com/redbrain/spy
> 
> Its only just starting to parse stuff but a kind of C/Python kind of
> language using gcc as a JIT might be interesting kind of dynamic
> language for C that can call C libs safely and easily is the idea.
> Mostly just so i can see where to help out in the jit front-end.

Excellent!  Looks promising - though it looks like the backend is all
stubbed out at the moment.

Note that the JIT API isn't frozen yet.  I try to remember to add "API
change" to the subject line when posting my commits, but I don't always
remember.

Let me know if you have any questions on how the JIT API works - or
input on how it *should* work.

FWIW I've been experimentally porting GNU Octave's LLVM-based JIT to
using libgccjit, and finding and fixing various issues in the latter on
the way - that's been driving a lot of the patches to the jit branch
lately.

> Was also considering some kind of libopcodes work to assemble the code
> in memory instead of creating a .so in /tmp. Not sure if i know what i
> am doing enough there but it might be more elegant for stuff using
> this front-end.

My thinking here was that the core code of the GNU assembler could gain
the option of being built as a shared library, and having to isolate
state in a "context" object, and we could try to hack the two projects
into meeting in the middle.  Large amount of work though (and a
different mailing list), hence the crude .so hack for now.

> Am so impressed how well this works.

Cheers!
Dave

On 12 February 2014 00:52, David Malcolm <dmalcolm@redhat.com> wrote:
> On Tue, 2014-02-11 at 16:51 +0000, Philip Herron wrote:
> [adding the jit@gcc.gnu.org ML to the CC]
>
>> Added install hook:
>
> Thanks!
>
> I don't know that this is needed for a 3-line patch, but have you done
> the copyright assignment paperwork for GCC contribution?  (I hope to
> merge my branch into gcc trunk at some point).  [Also, I'd love to have
> more, larger, patches from you for the jit branch!]

Yep i still have GCC copyright assignment.

> Excellent!  Looks promising - though it looks like the backend is all
> stubbed out at the moment.

Yeah only got started on it yesterday. Just need something to work
with the jit api to test and look to add features for.

>
> Note that the JIT API isn't frozen yet.  I try to remember to add "API
> change" to the subject line when posting my commits, but I don't always
> remember.
>

Yeah good point.

> Let me know if you have any questions on how the JIT API works - or
> input on how it *should* work.
>
> FWIW I've been experimentally porting GNU Octave's LLVM-based JIT to
> using libgccjit, and finding and fixing various issues in the latter on
> the way - that's been driving a lot of the patches to the jit branch
> lately.
>

Thats a good idea.

>> Was also considering some kind of libopcodes work to assemble the code
>> in memory instead of creating a .so in /tmp. Not sure if i know what i
>> am doing enough there but it might be more elegant for stuff using
>> this front-end.
>
> My thinking here was that the core code of the GNU assembler could gain
> the option of being built as a shared library, and having to isolate
> state in a "context" object, and we could try to hack the two projects
> into meeting in the middle.  Large amount of work though (and a
> different mailing list), hence the crude .so hack for now.
>

Yeah i was looking into it at the time and found, that trying to make
gas compile to a .so was a bit of a nightmare i couldn't get the
Makefile.am to regenerate its a funny autotools setup. But found
aparently libopcodes:

"The opcodes library contains functionality to assemble and
disassemble human readable assembly language to and from raw machine
code. "

http://www.toothycat.net/wiki/wiki.pl?Binutils

Might be something to look into.

--Phil

On Wed, 2014-02-12 at 09:53 +0000, Philip Herron wrote:
> On 12 February 2014 00:52, David Malcolm <dmalcolm@redhat.com> wrote:
> > On Tue, 2014-02-11 at 16:51 +0000, Philip Herron wrote:
> > [adding the jit@gcc.gnu.org ML to the CC]
> >
> >> Added install hook:
> >
> > Thanks!
> >
> > I don't know that this is needed for a 3-line patch, but have you done
> > the copyright assignment paperwork for GCC contribution?  (I hope to
> > merge my branch into gcc trunk at some point).  [Also, I'd love to have
> > more, larger, patches from you for the jit branch!]
> 
> Yep i still have GCC copyright assignment.

Thanks; I've committed and pushed this to the dmalcolm/jit branch (with
a ChangeLog.jit entry).