date:20090401

Hello Dear GCC Developers,



I would like to ask your opinion about possibility for integration of
the libJIT Just-In-Time compilation library and GCC. For example, the
same way as libffi is integrated within gcc source tree. It seems to
me that LLVM solves many goals that are already complete and solved in
GCC. So I think libJIT potentially is more useful for GCC and software
developers.


What is your opinion about this idea? How this should be done and what
improvements could be made to both libJIT and GCC for this kind of
integration?


I was also very surprised to read this interesting discussion by Rhys
Weatherley (libJIT) and Chris Lattner (LLVM) (libJIT vs LLVM):
http://lists.gnu.org/archive/html/dotgnu-libjit/2004-05/index.html


It talks more about differences in design and goals between libJIT and LLVM.


Please let me know your ideas and thoughts. No flaming please. I think
everyone benefits if we can gather enough thoughts about JITing in
GCC.


I also would like to point to my personal project about improvement of
libJIT: http://code.google.com/p/libjit-linear-scan-register-allocator/
. It studies how to make efficient code generation for Common
Intermediate Language and JIT compilers, and implements a full linear
scan register allocator and bin packing register allocator within
libJIT. It also has support of XMM registers for floating point
operations. The experimental target is the Microsoft Common
Intermediate Language. There is various data-flow and control-flow
analysis, including various liveness analysis(fast and full),
dead-code elimination etc with various optimization level. For
example, this code generator gives the following benchmark on my pc
for pnetmark at the moment, with Portable.NET Just-In-Time compiler
0.8.0:

LibJIT Linear Scan Register Allocator
Current  libJIT 0.1.2

Sieve      20439  17499
Loop       28311  24976
Logic      57311  55647
String     16586  16651
Float       2642   1940
Method   32426  30401

PnetMark(Average Score) 1900516970

The average improvement is 12% or so in pnetmark comparing to a global
register allocator in libJIT which uses number of usage of a variable
as an euristic.  With dead-code analysis enabled it jumps another 12%
or so. For example, the logic benchmark jumps over 70%. Other
optimizations enabled can give more improvement. It was remarkably
easy to add dead-code elimination in libJIT for example I spent less
than a week for this. But I am rather interested in the code
generation and linear scan register allocation at the moment and
Common Intermediate Language. I think GCC could benefit a lot if an
integration of both libJIT and GCC could be considered, and there was
cooperation about this.



Thanks,
Kirill

Re: GCC + libJIT instead of LLVM

And no this is not a 1st April joke :-)



Thanks,
Kirill

2009/4/1 Kirill Kononenko :
> Hello Dear GCC Developers,
>
>
>
> I would like to ask your opinion about possibility for integration of
> the libJIT Just-In-Time compilation library and GCC. For example, the
> same way as libffi is integrated within gcc source tree. It seems to
> me that LLVM solves many goals that are already complete and solved in
> GCC. So I think libJIT potentially is more useful for GCC and software
> developers.
>
>
> What is your opinion about this idea? How this should be done and what
> improvements could be made to both libJIT and GCC for this kind of
> integration?
>
>
> I was also very surprised to read this interesting discussion by Rhys
> Weatherley (libJIT) and Chris Lattner (LLVM) (libJIT vs LLVM):
> http://lists.gnu.org/archive/html/dotgnu-libjit/2004-05/index.html
>
>
> It talks more about differences in design and goals between libJIT and LLVM.
>
>
> Please let me know your ideas and thoughts. No flaming please. I think
> everyone benefits if we can gather enough thoughts about JITing in
> GCC.
>
>
> I also would like to point to my personal project about improvement of
> libJIT: http://code.google.com/p/libjit-linear-scan-register-allocator/
> . It studies how to make efficient code generation for Common
> Intermediate Language and JIT compilers, and implements a full linear
> scan register allocator and bin packing register allocator within
> libJIT. It also has support of XMM registers for floating point
> operations. The experimental target is the Microsoft Common
> Intermediate Language. There is various data-flow and control-flow
> analysis, including various liveness analysis(fast and full),
> dead-code elimination etc with various optimization level. For
> example, this code generator gives the following benchmark on my pc
> for pnetmark at the moment, with Portable.NET Just-In-Time compiler
> 0.8.0:
>
> LibJIT Linear Scan Register Allocator
> Current  libJIT 0.1.2
>
> Sieve      20439      17499
> Loop       28311      24976
> Logic      57311      55647
> String     16586      16651
> Float       2642       1940
> Method   32426      30401
>
> PnetMark(Average Score) 19005    16970
>
> The average improvement is 12% or so in pnetmark comparing to a global
> register allocator in libJIT which uses number of usage of a variable
> as an euristic.  With dead-code analysis enabled it jumps another 12%
> or so. For example, the logic benchmark jumps over 70%. Other
> optimizations enabled can give more improvement. It was remarkably
> easy to add dead-code elimination in libJIT for example I spent less
> than a week for this. But I am rather interested in the code
> generation and linear scan register allocation at the moment and
> Common Intermediate Language. I think GCC could benefit a lot if an
> integration of both libJIT and GCC could be considered, and there was
> cooperation about this.
>
>
>
> Thanks,
> Kirill
>

Re: GCC + libJIT instead of LLVM

Kirill Kononenko wrote:

> I would like to ask your opinion about possibility for integration of
> the libJIT Just-In-Time compilation library and GCC. For example, the
> same way as libffi is integrated within gcc source tree. It seems to
> me that LLVM solves many goals that are already complete and solved in
> GCC. So I think libJIT potentially is more useful for GCC and software
> developers.

Useful for what?  I think you have to tell us how this will improve the
experience of gcc users .

Andrew.

Re: GCC + libJIT instead of LLVM

More useful in implementation of Just-In-Time compilation in Virtual
Machine runtimes. For example, for Microsoft Common Intermediate
Language (.NET).


Thanks,
Kirill

2009/4/1 Andrew Haley :
> Kirill Kononenko wrote:
>
>> I would like to ask your opinion about possibility for integration of
>> the libJIT Just-In-Time compilation library and GCC. For example, the
>> same way as libffi is integrated within gcc source tree. It seems to
>> me that LLVM solves many goals that are already complete and solved in
>> GCC. So I think libJIT potentially is more useful for GCC and software
>> developers.
>
> Useful for what?  I think you have to tell us how this will improve the
> experience of gcc users .
>
> Andrew.
>

Re: GCC + libJIT instead of LLVM

> 2009/4/1 Andrew Haley :
>> Kirill Kononenko wrote:
>>
>>> I would like to ask your opinion about possibility for integration of
>>> the libJIT Just-In-Time compilation library and GCC. For example, the
>>> same way as libffi is integrated within gcc source tree. It seems to
>>> me that LLVM solves many goals that are already complete and solved in
>>> GCC. So I think libJIT potentially is more useful for GCC and software
>>> developers.
>> Useful for what?  I think you have to tell us how this will improve the
>> experience of gcc users .

Kirill Kononenko wrote:
> More useful in implementation of Just-In-Time compilation in Virtual
> Machine runtimes. For example, for Microsoft Common Intermediate
> Language (.NET).

We already know what a JIT does, thank you.  I think you have to tell us how
having libjit integrated in gcc will improve the experience of gcc users.
As opposed to them, say, using libjit as a library separate from gcc.

Andrew.

Re: GCC + libJIT instead of LLVM

>> 2009/4/1 Andrew Haley :
>>> Kirill Kononenko wrote:
>>>
 I would like to ask your opinion about possibility for integration of
 the libJIT Just-In-Time compilation library and GCC. For example, the
 same way as libffi is integrated within gcc source tree. It seems to
 me that LLVM solves many goals that are already complete and solved in
 GCC. So I think libJIT potentially is more useful for GCC and software
 developers.
>>> Useful for what?  I think you have to tell us how this will improve the
>>> experience of gcc users .
>
> Kirill Kononenko wrote:
>> More useful in implementation of Just-In-Time compilation in Virtual
>> Machine runtimes. For example, for Microsoft Common Intermediate
>> Language (.NET).
>
> We already know what a JIT does, thank you.  I think you have to tell us how

Please could you specify more precisely the 'we' here?

I really don't understand what you exactly mean here.

> having libjit integrated in gcc will improve the experience of gcc users.
> As opposed to them, say, using libjit as a library separate from gcc.
>

Just read my first post.


Thanks,
Kirill

Re: GCC + libJIT instead of LLVM

Kirill Kononenko wrote:
>>> 2009/4/1 Andrew Haley :
 Kirill Kononenko wrote:

> I would like to ask your opinion about possibility for integration of
> the libJIT Just-In-Time compilation library and GCC. For example, the
> same way as libffi is integrated within gcc source tree. It seems to
> me that LLVM solves many goals that are already complete and solved in
> GCC. So I think libJIT potentially is more useful for GCC and software
> developers.
 Useful for what?  I think you have to tell us how this will improve the
 experience of gcc users .
>> Kirill Kononenko wrote:
>>> More useful in implementation of Just-In-Time compilation in Virtual
>>> Machine runtimes. For example, for Microsoft Common Intermediate
>>> Language (.NET).
>> We already know what a JIT does, thank you.  I think you have to tell us how
> 
> Please could you specify more precisely the 'we' here?

Everybody who reads the gcc list knows what a JIT does.

> I really don't understand what you exactly mean here.
> 
>> having libjit integrated in gcc will improve the experience of gcc users.
>> As opposed to them, say, using libjit as a library separate from gcc.
> 
> Just read my first post.

I have, and you gave no reasons why this might help anyone.
I'm beginning to think this is an April Fool "joke".

Andrew.

Re: GCC + libJIT instead of LLVM

Kirill Kononenko wrote:
>>> 2009/4/1 Andrew Haley:
 Kirill Kononenko wrote:

> I would like to ask your opinion about possibility for integration of
> the libJIT Just-In-Time compilation library and GCC. For example, the
> same way as libffi is integrated within gcc source tree. It seems to
> me that LLVM solves many goals that are already complete and solved in
> GCC. So I think libJIT potentially is more useful for GCC and software
> developers.
 Useful for what?  I think you have to tell us how this will improve the
 experience of gcc users .
>> Kirill Kononenko wrote:
>>> More useful in implementation of Just-In-Time compilation in Virtual
>>> Machine runtimes. For example, for Microsoft Common Intermediate
>>> Language (.NET).
>> We already know what a JIT does, thank you.  I think you have to tell us how
> 
> Please could you specify more precisely the 'we' here?

  I think he means "Every single reader of the GCC mailing list, or as close
as makes no difference".

> I really don't understand what you exactly mean here.
> 
>> having libjit integrated in gcc will improve the experience of gcc users.
>> As opposed to them, say, using libjit as a library separate from gcc.
>>
> 
> Just read my first post.

  Hi, I also read your first post.  It says

> It seems to
> me that LLVM solves many goals that are already complete and solved in
> GCC. So I think libJIT potentially is more useful for GCC and software
> developers.

but you don't say what libjit would be more useful than, or how this overlap
between "solved goals" between gcc and llvm implies that.  Do you simply mean
that, because llvm and gcc both cover similar areas, and because libjit is
useful for llvm, it must also be useful for gcc?  Could you list some of these
goals and explain how they relate to JIT?

  You also wrote

> I think GCC could benefit a lot if an
> integration of both libJIT and GCC could be considered

but you don't explicitly describe any of the benefits you think will arise.
Can you enlarge on exactly what effect it would have if libjit was integrated
into GCC (presumably in the runtime support libraries somewhere) rather than
just existing as a separate installation?  I can't see how it would perform
any differently.

cheers,
  DaveK

Re: GCC + libJIT instead of LLVM

Basile STARYNKEVITCH wrote:

> The second issue (which perhaps Kirill did not thought of) would be to
> accelerate some internal optimisations of GCC by using JIT-code
> generation techniques within the compiler itself. There are several
> occasions within GCC where complex internal processing happens, and one
> could imagine to "partially evaluate" them (w.r.t. to the compiled
> source program) by generating some code specifically tuned to that
> processing. BTW, the MELT branch was designed with such stuff in mind,
> and indeed can generate some code (currently, it generates C code, run
> the host compiler on it, dlopen it, and use it; in principle I could
> have used libjit instead of forking a compilation process from inside cc1).

Yes, that's true.  But it doesn't in any sense require libjit to be integrated
with gcc to achieve this: the jit could just be called as an external library.

> I still don't understand what Kiril is thinking of exactly. In contrast
> to Andrew, I don't believe it is an April Fool's joke, but perhaps a
> language issue: both Kiril & me Basile are not native English speakers,
> and we may have difficulties in finding the right words & express
> ourself fluently in English.

For what it's worth, I didn't really think this is April Fool's joke; I was
just trying to provoke Kirill into explaining his purpose.  I seem to have
failed to do that.

Andrew.

Re: GCC + libJIT instead of LLVM


Kirill Kononenko wrote (citing me Basile)


The second issue (which perhaps Kirill did not thought of) would be to
accelerate some internal optimisations of GCC by using JIT-code generation
techniques within the compiler itself. There are several occasions within
GCC where complex internal processing happens, and one could imagine to
"partially evaluate" them (w.r.t. to the compiled source program) by
generating some code specifically tuned to that processing. BTW, the MELT
branch was designed with such stuff in mind, and indeed can generate some
code (currently, it generates C code, run the host compiler on it, dlopen
it, and use it; in principle I could have used libjit instead of forking a
compilation process from inside cc1).




Yes, this is exactly one kind of opportunity I see here. Basile is
absolutely correct here.

  


The standard answer to that would be : find an interesting use case (of 
JIT compilation inside GCC, eg inside some complex optimisation pass) 
and implement it in your branch.


I invested too much effort in C code generation in MELT, so I won't 
switch quickly to libjit, even if it could help a lot.


However, once the plugins machinery comes into the trunk, nothing 
prevent Kiril or others to experiment a plugin which uses libjit 
internally. And you (Kiril or others) could even start a branch right 
now (provided you did comply with the legal requirements of 
http://gcc.gnu.org/contribute.html ie the FSF copyright transfer).


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

Re: GCC + libJIT instead of LLVM

2009/4/1 Dave Korn :
> Kirill Kononenko wrote:
 2009/4/1 Andrew Haley:
> Kirill Kononenko wrote:
>
>> I would like to ask your opinion about possibility for integration of
>> the libJIT Just-In-Time compilation library and GCC. For example, the
>> same way as libffi is integrated within gcc source tree. It seems to
>> me that LLVM solves many goals that are already complete and solved in
>> GCC. So I think libJIT potentially is more useful for GCC and software
>> developers.
> Useful for what?  I think you have to tell us how this will improve the
> experience of gcc users .
>>> Kirill Kononenko wrote:
 More useful in implementation of Just-In-Time compilation in Virtual
 Machine runtimes. For example, for Microsoft Common Intermediate
 Language (.NET).
>>> We already know what a JIT does, thank you.  I think you have to tell us how
>>
>> Please could you specify more precisely the 'we' here?
>
>  I think he means "Every single reader of the GCC mailing list, or as close
> as makes no difference".
>
>> I really don't understand what you exactly mean here.
>>
>>> having libjit integrated in gcc will improve the experience of gcc users.
>>> As opposed to them, say, using libjit as a library separate from gcc.
>>>
>>
>> Just read my first post.
>
>  Hi, I also read your first post.  It says
>
>> It seems to
>> me that LLVM solves many goals that are already complete and solved in
>> GCC. So I think libJIT potentially is more useful for GCC and software
>> developers.
>
> but you don't say what libjit would be more useful than, or how this overlap
> between "solved goals" between gcc and llvm implies that.  Do you simply mean
> that, because llvm and gcc both cover similar areas, and because libjit is
> useful for llvm, it must also be useful for gcc?  Could you list some of these
> goals and explain how they relate to JIT?
>
>  You also wrote
>
>> I think GCC could benefit a lot if an
>> integration of both libJIT and GCC could be considered
>
> but you don't explicitly describe any of the benefits you think will arise.
> Can you enlarge on exactly what effect it would have if libjit was integrated
> into GCC (presumably in the runtime support libraries somewhere) rather than
> just existing as a separate installation?  I can't see how it would perform
> any differently.

LLVM is an overkill for JIT compilation. I think the tasks which LLVM
solves are already solved within GCC transformations, or can be
integrated very easily with libJIT. LibJIT is also much easier in
usage, for ordinary developers. So what I see here, LLVM is rather a
competitor to GCC, considering which tasks it solves. And complexity
of code rises inproportionally to the task it is used for. While both
could be potentionaly useful for their area of expertise. I think an
GCC+libJIT solves 99% of areas of LLVM usage.


Thanks,
Kirill

Re: GCC + libJIT instead of LLVM

>> The second issue (which perhaps Kirill did not thought of) would be to
>> accelerate some internal optimisations of GCC by using JIT-code
>> generation techniques within the compiler itself. There are several
>> occasions within GCC where complex internal processing happens, and one
>> could imagine to "partially evaluate" them (w.r.t. to the compiled
>> source program) by generating some code specifically tuned to that
>> processing. BTW, the MELT branch was designed with such stuff in mind,
>> and indeed can generate some code (currently, it generates C code, run
>> the host compiler on it, dlopen it, and use it; in principle I could
>> have used libjit instead of forking a compilation process from inside cc1).
>
> Yes, that's true.  But it doesn't in any sense require libjit to be integrated
> with gcc to achieve this: the jit could just be called as an external library.
>
>> I still don't understand what Kiril is thinking of exactly. In contrast
>> to Andrew, I don't believe it is an April Fool's joke, but perhaps a
>> language issue: both Kiril & me Basile are not native English speakers,
>> and we may have difficulties in finding the right words & express
>> ourself fluently in English.
>
> For what it's worth, I didn't really think this is April Fool's joke; I was

Everyone who read that, might have thought you really meant that.

> just trying to provoke Kirill into explaining his purpose.  I seem to have
> failed to do that.
>

My explanations seem to have also failed to explain you.
Unfortunately, one really needs have some back group with both
Just-In-Time compilers,Virtual Machines, and Common Intermediate
Language to understand this area. I understand that it is not your
area of expertise, so it is not an issue for me.


Thanks,
Kirill

Re: GCC + libJIT instead of LLVM

> However, I see several interesting issues raised here:
>
> the first is to [re-]use GCC for just in time compilation, for instance to
> JIT-compile CLI or JVM bytecode into machine code, or even C or some
> specialized gimple-like representation into machine code, or CLISP into
> machine code, all this using most of existing code in GCC (certainly the
> middle-end and a back-end). This might be doable, is certainly interesting
> (I heard even that some major GCC contributor[s] wanted that to happen), but
> remains difficult (because GCC was not designed for that). Note that libjit
> per se is not useful in that case, but GCC would be made as a server (or a
> library) which happens to deliver some of libjit or LLVM functionalities
> (the ability to generate code).
>
> The second issue (which perhaps Kirill did not thought of) would be to
> accelerate some internal optimisations of GCC by using JIT-code generation
> techniques within the compiler itself. There are several occasions within
> GCC where complex internal processing happens, and one could imagine to
> "partially evaluate" them (w.r.t. to the compiled source program) by
> generating some code specifically tuned to that processing. BTW, the MELT
> branch was designed with such stuff in mind, and indeed can generate some
> code (currently, it generates C code, run the host compiler on it, dlopen
> it, and use it; in principle I could have used libjit instead of forking a
> compilation process from inside cc1).


Yes, this is exactly one kind of opportunity I see here. Basile is
absolutely correct here.


>
> I still don't understand what Kiril is thinking of exactly. In contrast to
> Andrew, I don't believe it is an April Fool's joke, but perhaps a language
> issue: both Kiril & me Basile are not native English speakers, and we may
> have difficulties in finding the right words & express ourself fluently in
> English. If it is the case please forgive us (or just try to interact on a
> french or russian mailing list!).
>


Thanks,
Kirill

Re: GCC + libJIT instead of LLVM


Andrew Haley wrote:

Useful for what?  I think you have to tell us how this will improve the
experience of gcc users .
  


Kirill Kononenko wrote:
  

More useful in implementation of Just-In-Time compilation in Virtual
Machine runtimes. For example, for Microsoft Common Intermediate
Language (.NET).



We already know what a JIT does, thank you.  I think you have to tell us how
having libjit integrated in gcc will improve the experience of gcc users.
As opposed to them, say, using libjit as a library separate from gcc.
  


I still do not understand exactly what Kirill Kononenko is thinking about.

However, I see several interesting issues raised here:

the first is to [re-]use GCC for just in time compilation, for instance 
to JIT-compile CLI or JVM bytecode into machine code, or even C or some 
specialized gimple-like representation into machine code, or CLISP into 
machine code, all this using most of existing code in GCC (certainly the 
middle-end and a back-end). This might be doable, is certainly 
interesting (I heard even that some major GCC contributor[s] wanted that 
to happen), but remains difficult (because GCC was not designed for 
that). Note that libjit per se is not useful in that case, but GCC would 
be made as a server (or a library) which happens to deliver some of 
libjit or LLVM functionalities (the ability to generate code).


The second issue (which perhaps Kirill did not thought of) would be to 
accelerate some internal optimisations of GCC by using JIT-code 
generation techniques within the compiler itself. There are several 
occasions within GCC where complex internal processing happens, and one 
could imagine to "partially evaluate" them (w.r.t. to the compiled 
source program) by generating some code specifically tuned to that 
processing. BTW, the MELT branch was designed with such stuff in mind, 
and indeed can generate some code (currently, it generates C code, run 
the host compiler on it, dlopen it, and use it; in principle I could 
have used libjit instead of forking a compilation process from inside cc1).


I still don't understand what Kiril is thinking of exactly. In contrast 
to Andrew, I don't believe it is an April Fool's joke, but perhaps a 
language issue: both Kiril & me Basile are not native English speakers, 
and we may have difficulties in finding the right words & express 
ourself fluently in English. If it is the case please forgive us (or 
just try to interact on a french or russian mailing list!).


Regards.

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

Re: GCC + libJIT instead of LLVM

2009/4/1 Andrew Haley :
> Kirill Kononenko wrote:
 2009/4/1 Andrew Haley :
> Kirill Kononenko wrote:
>
>> I would like to ask your opinion about possibility for integration of
>> the libJIT Just-In-Time compilation library and GCC. For example, the
>> same way as libffi is integrated within gcc source tree. It seems to
>> me that LLVM solves many goals that are already complete and solved in
>> GCC. So I think libJIT potentially is more useful for GCC and software
>> developers.
> Useful for what?  I think you have to tell us how this will improve the
> experience of gcc users .
>>> Kirill Kononenko wrote:
 More useful in implementation of Just-In-Time compilation in Virtual
 Machine runtimes. For example, for Microsoft Common Intermediate
 Language (.NET).
>>> We already know what a JIT does, thank you.  I think you have to tell us how
>>
>> Please could you specify more precisely the 'we' here?
>
> Everybody who reads the gcc list knows what a JIT does.
>
>> I really don't understand what you exactly mean here.
>>
>>> having libjit integrated in gcc will improve the experience of gcc users.
>>> As opposed to them, say, using libjit as a library separate from gcc.
>>
>> Just read my first post.
>
> I have, and you gave no reasons why this might help anyone.
> I'm beginning to think this is an April Fool "joke".

Please let me know who are the 'we' in your previous post?

I' m beginning to think that you have a personal interest here. I
think you either meant there "I" or your company in which you work
full-time, and get your paycheck. I am correct to suppose this? I am
beginning to think that this is an April Fool "joke" of your part.


Thanks,
Kirill

Re: GCC + libJIT instead of LLVM

2009/4/1 Basile STARYNKEVITCH :
>>>
>>> The second issue (which perhaps Kirill did not thought of) would be to
>>> accelerate some internal optimisations of GCC by using JIT-code
>>> generation
>>> techniques within the compiler itself. There are several occasions within
>>> GCC where complex internal processing happens, and one could imagine to
>>> "partially evaluate" them (w.r.t. to the compiled source program) by
>>> generating some code specifically tuned to that processing. BTW, the MELT
>>> branch was designed with such stuff in mind, and indeed can generate some
>>> code (currently, it generates C code, run the host compiler on it, dlopen
>>> it, and use it; in principle I could have used libjit instead of forking
>>> a
>>> compilation process from inside cc1).
>>>
>>
>>
>> Yes, this is exactly one kind of opportunity I see here. Basile is
>> absolutely correct here.
>>
>>
>
> The standard answer to that would be : find an interesting use case (of JIT
> compilation inside GCC, eg inside some complex optimisation pass) and
> implement it in your branch.
>
> I invested too much effort in C code generation in MELT, so I won't switch
> quickly to libjit, even if it could help a lot.
>
> However, once the plugins machinery comes into the trunk, nothing prevent
> Kiril or others to experiment a plugin which uses libjit internally. And you
> (Kiril or others) could even start a branch right now (provided you did
> comply with the legal requirements of http://gcc.gnu.org/contribute.html ie
> the FSF copyright transfer).
>

Thank you a lot, Basile, for your support.



Thanks,
Kirill

Re: stdint.h type information needed

2009-04-01 Thread Joseph S. Myers

On Tue, 31 Mar 2009, DJ Delorie wrote:

> > I expect most of the OSes listed do; the types should still be entered 
> > into GCC (so the Fortran front end can know them, for example), and 
> 
> Well, I'm not a big fan of duplicating information, but if that's what
> you want to do, here it is.  Enjoy.

I'm hoping the maintainers of OS support in GCC, or other people set up to 
test on each OS, will put the types in an appropriate tm.h header and test 
that the c99-stdint-*.c tests pass.  Adding the information myself without 
testing is very much a last resort.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: GCC + libJIT instead of LLVM

Kirill Kononenko wrote:

> LLVM is an overkill for JIT compilation. I think the tasks which LLVM
> solves are already solved within GCC transformations, or can be
> integrated very easily with libJIT. LibJIT is also much easier in
> usage, for ordinary developers. So what I see here, LLVM is rather a
> competitor to GCC, considering which tasks it solves. And complexity
> of code rises inproportionally to the task it is used for. While both
> could be potentionaly useful for their area of expertise. I think an
> GCC+libJIT solves 99% of areas of LLVM usage.

  From this, it sounds to me as if the question you should be asking is not so
much "Could integrating libjit be useful for GCC", but more like "Could
integrating GCC be useful for libjit"!

cheers,
  DaveK

Re: stdint.h type information needed

2009-04-01 Thread Joseph S. Myers

On Wed, 1 Apr 2009, Bernd Roesch wrote:

> Hello Joseph
> 
> On 01.04.09, you wrote:
> 
> I add this file some time ago to Amiga OS 68k target, and build compiler, in
> config.log files during compiler build, it seem detect right, are there
> still defines in config.gcc need and other defines ?

Yes, the main changes needed are definitions in a tm.h header like those 
in sol2.h:

#define INT8_TYPE "char"
#define INT16_TYPE "short int"
...

after which a definition of use_gcc_stdint can be added to config.gcc.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: GCC + libJIT instead of LLVM

Kirill and Andrew wrote:

>> "April Fool's joke"
> "not your area of expertise"

  Maybe it would be for the best if you two started over, before this turns 
sour.

cheers,
  DaveK

Re: stdint.h type information needed

Joseph S. Myers wrote:

> I'm hoping the maintainers of OS support in GCC, or other people set up to 
> test on each OS, will put the types in an appropriate tm.h header and test 
> that the c99-stdint-*.c tests pass.  Adding the information myself without 
> testing is very much a last resort.

  I'll take care of this during the week for Cygwin.  (It'll take me at least
a few days).

cheers,
  DaveK

Re: GCC + libJIT instead of LLVM

2009/4/1 Dave Korn :
>> LLVM is an overkill for JIT compilation. I think the tasks which LLVM
>> solves are already solved within GCC transformations, or can be
>> integrated very easily with libJIT. LibJIT is also much easier in
>> usage, for ordinary developers. So what I see here, LLVM is rather a
>> competitor to GCC, considering which tasks it solves. And complexity
>> of code rises inproportionally to the task it is used for. While both
>> could be potentionaly useful for their area of expertise. I think an
>> GCC+libJIT solves 99% of areas of LLVM usage.
>
>  From this, it sounds to me as if the question you should be asking is not so
> much "Could integrating libjit be useful for GCC", but more like "Could
> integrating GCC be useful for libjit"!

LibJIT is a not a competitor to LLVM. Three guys on internet don't
compete with a multi-billion corporation like Apple (?) But you are
correct. LibJIT is only a tool for JITing, and it already does this
job much better than any other tool. LibJIT can benefit even more from
integration with GCC internals.


Thanks,
Kirill

Invalid reload inheritance with paradoxical subregs

2009-04-01 Thread Uros Bizjak

Hello!

I have encountered a problem with a private RISC target, where invalid
reload is generated when paradoxical registers are involved.

In a lreg pass, I have a sequence of instructions:

(insn 112 182 114 2 t.c:22 (set (mem/s/j/c:SI (plus:SI (reg/f:SI 35 frame)
(const_int -20 [0xffec])) [0+4 S4 A32])
(reg:SI 129)) 9 {*movsi_internal_ba1} (nil))

...

(insn 116 115 117 2 t.c:22 (set (mem/s/c:HI (plus:SI (reg/f:SI 35 frame)
(const_int -8 [0xfff8])) [2 y+4 S2 A32])
(subreg:HI (reg:SI 129) 0)) 2 {*movhi_internal_ba1}
(expr_list:REG_DEAD (reg:SI 129)
(nil)))

...

(insn 121 120 125 2 t.c:22 (set (reg:SI 48 [ y$k.115 ])
(lshiftrt:SI (subreg:SI (mem/s/c:HI (plus:SI (reg/f:SI 35 frame)
(const_int -8 [0xfff8])) [0+4 S2 A32]) 0)
(const_int 5 [0x5]))) 62 {lshrsi3} (nil))


(reg 129) is stored in HImode to a HImode stack slot. Since this is
ZERO_EXTEND LOAD_EXTEND_OP RISC target with WORD_REGISTER_OPERATIONS,
we zero extend the value when the value is loaded from memory in (insn
121). Effectively, we clear top 16 bits before we shift them.

After reload, this same sequence reads as:

(insn 112 182 114 2 t.c:22 (set (mem/s/j/c:SI (plus:SI (reg/f:SI 1 r1)
(const_int 4 [0x4])) [0+4 S4 A32])
(reg:SI 7 r7 [129])) 9 {*movsi_internal_ba1} (nil))

...

(insn 116 115 117 2 t.c:22 (set (mem/s/c:HI (plus:SI (reg/f:SI 1 r1)
(const_int 16 [0x10])) [2 y+4 S2 A32])
(reg:HI 7 r7 [129])) 2 {*movhi_internal_ba1} (nil))

...

(insn 121 120 125 2 t.c:22 (set (reg:SI 6 r6 [orig:48 y$k.115 ] [48])
(lshiftrt:SI (reg:SI 7 r7)
(const_int 5 [0x5]))) 62 {lshrsi3} (nil))


A SImode value is stored in (insn 112) and a HImode lowpart value is
stored from the same register to different value in (insn 116).
However, in (insn 121) a HImode store/load sequence that would clear
top 16 bits is simply replaced with a SImode register access. Since
the top 16 bits are _not_ guaranteed to be zero in (insn 121),
undefined bits are shifted in, leading to the wrong value in r6.

I would like to fix this problem, so if anybody (a reload expert
perhaps ;) has any advice where to look in reload1.c, I'd be more than
happy to debug and test the fix for this problem.

Thanks,
Uros.

Re: Revised GCC Runtime Library Exception

Is that an April fool's joke?

The new license allows Java, but it does not allow linking with
code that has no dependency on the Runtime Library whatsoever
(because it is not considered 'Independent Modules'), and it does not
allow linking with code that has been written in assembly language
(it is not considered Target Code).
I.e. we are back to square one, gcc output can only be conveyed under
the terms of the GPL. 
This e-mail was sent from a group e-mail system of ARC International Plc. Full 
details of the registered names and addresses of companies within the ARC group 
can be found on the ARC website.ARC International plc, Registered Office: 
Verulam Point, Station WaySt. Albans AL1 5HE United Kingdom Registered in 
England and Wales No.  3592130savm-exch03

Re: GCC + libJIT instead of LLVM

Dave Korn wrote:
> Kirill and Andrew wrote:
> 
>>> "April Fool's joke"
>> "not your area of expertise"
> 
>   Maybe it would be for the best if you two started over, before this turns 
> sour.

I'm out of here already!  All I can say is that I hope my boss never finds
out that virtual machines and JITs are not my area of expertise.  :-)

Andrew.

Re: GCC + libJIT instead of LLVM

>> Kirill and Andrew wrote:
>>
 "April Fool's joke"
>>> "not your area of expertise"
>>
>>   Maybe it would be for the best if you two started over, before this turns 
>> sour.
>
> I'm out of here already!  All I can say is that I hope my boss never finds
> out that virtual machines and JITs are not my area of expertise.  :-)

You are lucky :-) Most luckely your company won't assume that it has
spend so much money in LLVM investment without results.

You can just try libJIT if you want to compare. As I understand it is
very easy to use or convert something done for one in another.

Thanks,
Kirill

Re: Revised GCC Runtime Library Exception

On Wed, Apr 1, 2009 at 3:18 PM, Joern Rennecke  wrote:
> Is that an April fool's joke?
>
> The new license allows Java, but it does not allow linking with
> code that has no dependency on the Runtime Library whatsoever
> (because it is not considered 'Independent Modules'), and it does not

How would the runtime license apply or be an issue if the runtime is not
needed?

> allow linking with code that has been written in assembly language
> (it is not considered Target Code).

As I read it assembly language is target code but at the same time may be
'non-intermediate languages designed for human-written code', so I fail
to see your issue here.

What I do find strange is the restriction to explicitly Java VM bytecode
(not CIL or others).

Richard.

Re: Invalid reload inheritance with paradoxical subregs

I suggest you first find out more what is exactly reloaded and where
the inheritance occurs - inheritance can be done by choose_reload_regs
or later in emit_reload_insns and its subfunctions.

I.e. set a breakpoint on find_reloads and make it conditional on
insn->u.fld[0].rt_int == 121 && replace
, let the compilation break there, finish, and call debug_reload()
to look at the scheduled reloads.
Then set a breakpoint on choose_reload_regs, make it conditional on
chain->insn->u.fld[0].rt_int == 121
, continue to the breakpoint, finish, and call debug_reload() again.
This should tell you what MEM is actually reloaded, and if the inheritance
already happens there; depending on what you find, you have to look further
in choose_reload_regs or in the reload emitting code. 
This e-mail was sent from a group e-mail system of ARC International Plc. Full 
details of the registered names and addresses of companies within the ARC group 
can be found on the ARC website.ARC International plc, Registered Office: 
Verulam Point, Station WaySt. Albans AL1 5HE United Kingdom Registered in 
England and Wales No.  3592130savm-exch03

Re: Revised GCC Runtime Library Exception

On Wed, Apr 01, 2009 at 03:30:25PM +0200, Richard Guenther wrote:
> On Wed, Apr 1, 2009 at 3:18 PM, Joern Rennecke  wrote:
> > Is that an April fool's joke?
> >
> > The new license allows Java, but it does not allow linking with
> > code that has no dependency on the Runtime Library whatsoever
> > (because it is not considered 'Independent Modules'), and it does not
> 
> How would the runtime license apply or be an issue if the runtime is not
> needed?

Say you have module A, B, C and D.  A is the main program and uses B, C
and D.  B uses the runtime library, and is therefore an independent module.
Thus, you are allowed to link B with the runtime library.  An argument
could be made that A is an independent module because it depends on B,
although that seems a bit risky to bet a companies fortunes on.
At any rate C and D are not independent modules, because they don't need
the runtime library.  Hence you are only allowed to convey a work of Target
Code comprising A, B, C and D together with (parts of) the Runtime Library
under the terms of the GPL, if at all.

> As I read it assembly language is target code but at the same time may be

Hand-written assembly language is not the output of a compiler, and
thus is not Target Code.

> 'non-intermediate languages designed for human-written code', so I fail
> to see your issue here.

I would agree that it fits the 'non-intermediate languages designed
for human-written code' category, but the exception only applies to a work
of Target Code.  In the absence of a more inclusive definition of compiler,
I have to assume that a compiler would take a high level language as input.
Hence, assembly language is neither Target Code, nor can it be transformed
into Target Code, unless you can first transform it into a high level
language in order for it to be compiled. 
This e-mail was sent from a group e-mail system of ARC International Plc. Full 
details of the registered names and addresses of companies within the ARC group 
can be found on the ARC website.ARC International plc, Registered Office: 
Verulam Point, Station WaySt. Albans AL1 5HE United Kingdom Registered in 
England and Wales No.  3592130savm-exch03

generating functions and eh region

2009-04-01 Thread Vincent R.

Sorry to cross-post here because I have started this discussion on gcc-help
but since we are trying to interest people about seh exceptions it might be
better
to do it here.
I first asked how to take some instructions and generate a function with
them,
so I wanted to know if start_function was the right way of doing it.
I have been told(thanks Ian) that if the function is only reached through
exceptions I would need to
look at eh region and here is the following question : 

 
Actually you are right the only way the function is called is through
exception.
When exception is raised OS will look for some exception information stored
inside specific sections and
jump to that filter function.
Now the question is can we declare a function with an eh region and will it
construct prologue and epilogue ?
Actually the __except keyword can be declared with two flavors :

1) __except( INSA, INSSB, ...) where INSX are instructions 

2) __except( FILTER_FUNC ) where FILTER_FUNC is a function 
with the following prototype : int (*ptFilter)(unsigned int code,
struct _EXCEPTION_POINTERS *ep);

So in case 1) we need to take instructions inside __except() and to put
them in a
function, it means we need gcc
to construct prologue and epilogue. I suppose eh_region is only used to
mark code and prevent it to be optimized
and discarded but it doesn't solve the fact we need to construct a
function.
So we may need to call start_function
anyway, what do you think ?

In the second case we can pass directly a function so this time I suppose
we only need to declare it as
a eh_region. Could you confirm I am understanding well the purpose of
eh_region and tell us 
if  we are looking in the right direction.

Thanks


Vincent R.

Re: Revised GCC Runtime Library Exception

Richard Guenther wrote:
> 
> What I do find strange is the restriction to explicitly Java VM bytecode
> (not CIL or others).

I think I understand that one.  Way back in time, when gcj was contributed
by Cygnus, the FSF had to be convinced that Java VM bytecode couldn't be
used to allow, e.g., an unfree C++ front-end to be bolted onto the gcc
back-end.  In truth it could be in theory , but the semantics of the
Java VM mean that the result would not be any good.

Andrew.

Re: Revised GCC Runtime Library Exception

2009-04-01 Thread David Edelsohn

Joern,

The FSF and SFLC believes that your concerns best can be addressed in the FAQ.

David

On Wed, Apr 1, 2009 at 9:18 AM, Joern Rennecke  wrote:
> Is that an April fool's joke?
>
> The new license allows Java, but it does not allow linking with
> code that has no dependency on the Runtime Library whatsoever
> (because it is not considered 'Independent Modules'), and it does not
> allow linking with code that has been written in assembly language
> (it is not considered Target Code).
> I.e. we are back to square one, gcc output can only be conveyed under
> the terms of the GPL.
> This e-mail was sent from a group e-mail system of ARC International Plc. 
> Full details of the registered names and addresses of companies within the 
> ARC group can be found on the ARC website.ARC International plc, Registered 
> Office: Verulam Point, Station WaySt. Albans AL1 5HE United Kingdom 
> Registered in England and Wales No.  3592130savm-exch03

Re: Revised GCC Runtime Library Exception

"Joern Rennecke"  writes:

> On Wed, Apr 01, 2009 at 03:30:25PM +0200, Richard Guenther wrote:
>> On Wed, Apr 1, 2009 at 3:18 PM, Joern Rennecke  wrote:
>> > Is that an April fool's joke?
>> >
>> > The new license allows Java, but it does not allow linking with
>> > code that has no dependency on the Runtime Library whatsoever
>> > (because it is not considered 'Independent Modules'), and it does not
>> 
>> How would the runtime license apply or be an issue if the runtime is not
>> needed?
>
> Say you have module A, B, C and D.  A is the main program and uses B, C
> and D.  B uses the runtime library, and is therefore an independent module.
> Thus, you are allowed to link B with the runtime library.  An argument
> could be made that A is an independent module because it depends on B,
> although that seems a bit risky to bet a companies fortunes on.
> At any rate C and D are not independent modules, because they don't need
> the runtime library.  Hence you are only allowed to convey a work of Target
> Code comprising A, B, C and D together with (parts of) the Runtime Library
> under the terms of the GPL, if at all.

A, B, C and D considered together are an independent module.  There is
no reason to separate C and D here.

Earlier Bradley Kuhn had indicated that this would be covered in the
updated FAQ, but I don't really see it there.  I sent him a separate
message asking him to update it.

Ian

Re: generating functions and eh region

"Vincent R."  writes:

> Now the question is can we declare a function with an eh region and will it
> construct prologue and epilogue ?

The instructions are already in a function.  Why do you need a separate
prologue and epilogue for them?

Maybe I am missing the point here.  It seems to me that the __except
keyword as you described it can be implemented by a transformation from
C++ to C++.  gcc already knows how to handle exception regions; you
don't have to teach it anything in that area.  You just have to generate
the correct GIMPLE or GENERIC in the frontend.  You are talking about
creating a new function, but I just don't see any reason to do so.  You
already have a function, and you can just create exception regions in
that function.  The code in the exception region can call other
functions, etc.  What am I missing?

Ian

[graphite] Weekly phone call - Automatic parallelization

2009-04-01 Thread Tobias Grosser

Hi,

to keep everybody updated what is happening in the GRAPHITE branch, I
would like to post the notes of our weekly phone call.

Attendees: Razya, Li, Konrad, Jan, Tobi, David, Sebastian, Christophe 

Discussed topics: 

  * Data dependencies: Tobias committed a patch filling the access
polyhedrons 
  * Not yet enabled as there are some bootstrap bugs 
  * All arrays access the same alias set 
  * Reductions are not yet included in the access
polyhedrons (Same as last week, but now really
committed) 
  * Bug in building of scattering matrices fixed. 
  * Bug in condition detection on its way to be fixed. 
  * Automatic Parallelization: 
  * Li will start integrating graphite and code generation
(If his summer of code proposal is accepted) 
  * Mark all loops parallel if new flag
"-fgraphite-force-parallel" is set. 
  * How to connect auto par? 
  * Directly in graphite code generation (clast to
gimple): We call the autopar backend after
generating a serial gimple loop. This is the
easiest approach. Also we still access to the
polyhedral information so we can use it to give
autopar more information. 
  * By annotating loops: In the graphite pass we
annotate gimple loops as parallel . Later the
autopar pass is scheduled, which bypasses its
analysis if it sees a loop annotated parallel.
This allows to schedule scalar optimizations in
between graphite and autopar, but we loose the
polyhedral information. As we do not need the
additional information, but we definitely need
some scalar optimization like PRE the
"annotating loops" approach seems to be our
first try. 

The notes of all calls are available on the wiki:
http://gcc.gnu.org/wiki/Graphite_Phone_Call

More information about graphite at:
http://gcc.gnu.org/wiki/Graphite

Tobi

Re: GCC + libJIT instead of LLVM

2009-04-01 Thread David Edelsohn

On Wed, Apr 1, 2009 at 8:14 AM, Kirill Kononenko
 wrote:

> My explanations seem to have also failed to explain you.
> Unfortunately, one really needs have some back group with both
> Just-In-Time compilers,Virtual Machines, and Common Intermediate
> Language to understand this area. I understand that it is not your
> area of expertise, so it is not an issue for me.

I think a JIT associated with GCC would be great.  Not everything is
static compilation.  "Split Compilation" combining static compilation
for complicated analysis along with a "Managed Runtime" for
execution and runtime transformations is becoming more important.

libJIT could help with the runtime for a GCC implementation of OpenCL.
It could help with an environment for Java and CIL.

A JIT associated with GCC would allow coordination between GCC
bytecode generation and the JIT.  It also can allow the JIT cache
to be pre-warmed by GCC static code and profiling information.

There are many exciting opportunities.

David

Re: generating functions and eh region

2009-04-01 Thread Vincent R.

On Wed, 01 Apr 2009 07:54:20 -0700, Ian Lance Taylor 
wrote:
> "Vincent R."  writes:
> 
>> Now the question is can we declare a function with an eh region and will
>> it
>> construct prologue and epilogue ?
> 
> The instructions are already in a function.  Why do you need a separate
> prologue and epilogue for them?
> 
> Maybe I am missing the point here.  It seems to me that the __except
> keyword as you described it can be implemented by a transformation from
> C++ to C++.  gcc already knows how to handle exception regions; you
> don't have to teach it anything in that area.  You just have to generate
> the correct GIMPLE or GENERIC in the frontend.  You are talking about
> creating a new function, but I just don't see any reason to do so.  You
> already have a function, and you can just create exception regions in
> that function.  The code in the exception region can call other
> functions, etc.  What am I missing?
> 
> Ian

Yes I think I don't explain things very clearly, so what is important to
know is that the __except keyword
can be passed instructions(case 1) or directly a function(case 2).

in the case 1)  ie if you declare something like :

...
__except( printf("hello gcc"), 1)

and I look at asm generated I can notice that the instructions inside the
patenthesis will be put inside a function
because I can notice a prologue and epilogue.



int main()
{
...
  __except(puts("in filter"), EXCEPTION_EXECUTE_HANDLER)
  {
...
  }
} // main
...


So on a arm plateform here is the annoted asm (asm + source code), I have
only pasted the __except part :
And we can see that just after the closing } for main there is a prologue
followed by the instructions
originally in the __except and then the epilogue.


// main }
; 128  :__except(puts("in filter"), EXCEPTION_EXECUTE_HANDLER){

str lr, [sp, #-4]!   function prologue
|$...@wmain|
|$l...@wmain|
ldr r0, [pc, #8]
bl  puts
mov r0, #1
|$...@wmain|
ldr pc, [sp], #4  function epilogue


so instructions inside __except parenthesis are put in something that looks
like a function

Do I need to explain more ?

Re: GCC + libJIT instead of LLVM

>
>> My explanations seem to have also failed to explain you.
>> Unfortunately, one really needs have some back group with both
>> Just-In-Time compilers,Virtual Machines, and Common Intermediate
>> Language to understand this area. I understand that it is not your
>> area of expertise, so it is not an issue for me.
>
> I think a JIT associated with GCC would be great.  Not everything is
> static compilation.  "Split Compilation" combining static compilation
> for complicated analysis along with a "Managed Runtime" for
> execution and runtime transformations is becoming more important.
>
> libJIT could help with the runtime for a GCC implementation of OpenCL.
> It could help with an environment for Java and CIL.
>
> A JIT associated with GCC would allow coordination between GCC
> bytecode generation and the JIT.  It also can allow the JIT cache
> to be pre-warmed by GCC static code and profiling information.
>
> There are many exciting opportunities.


Thank you David this excellent explanation. I also think that there
are many exciting opportunities.



Thanks,
Kirill

Re: GCC + libJIT instead of LLVM

>>> My explanations seem to have also failed to explain you.
>>> Unfortunately, one really needs have some back group with both
>>> Just-In-Time compilers,Virtual Machines, and Common Intermediate
>>> Language to understand this area. I understand that it is not your
>>> area of expertise, so it is not an issue for me.
>>
>> I think a JIT associated with GCC would be great.  Not everything is
>> static compilation.  "Split Compilation" combining static compilation
>> for complicated analysis along with a "Managed Runtime" for
>> execution and runtime transformations is becoming more important.
>>
>> libJIT could help with the runtime for a GCC implementation of OpenCL.
>> It could help with an environment for Java and CIL.
>>
>> A JIT associated with GCC would allow coordination between GCC
>> bytecode generation and the JIT.  It also can allow the JIT cache
>> to be pre-warmed by GCC static code and profiling information.
>>
>> There are many exciting opportunities.
>
>

Thank you David for this excellent explanation. I also think that
there are many exciting opportunities.


Thanks,
Kirill

Re: generating functions and eh region

"Vincent R."  writes:

> Yes I think I don't explain things very clearly, so what is important to
> know is that the __except keyword
> can be passed instructions(case 1) or directly a function(case 2).

I see that but I don't see why it matters.

> in the case 1)  ie if you declare something like :
>
> ...
> __except( printf("hello gcc"), 1)
>
> and I look at asm generated I can notice that the instructions inside the
> patenthesis will be put inside a function
> because I can notice a prologue and epilogue.

What asm are you looking at?

gcc will do the right thing if you put statements in an exception
region.

> So on a arm plateform here is the annoted asm (asm + source code), I have
> only pasted the __except part :

I don't understand why the fact that some compiler generates a prologue
and epilogue implies anything about what gcc should do.  The definition
of this language construct is presumably not written in terms of
prologues and epilogues.  It is presumably written in terms of "execute
these statements, then do this."

Ian

Re: GCC + libJIT instead of LLVM

2009-04-01 Thread Chris Lattner


On Apr 1, 2009, at 5:09 AM, Dave Korn wrote:

It seems to
me that LLVM solves many goals that are already complete and solved  
in
GCC. So I think libJIT potentially is more useful for GCC and  
software

developers.


but you don't say what libjit would be more useful than, or how this  
overlap
between "solved goals" between gcc and llvm implies that.  Do you  
simply mean
that, because llvm and gcc both cover similar areas, and because  
libjit is
useful for llvm, it must also be useful for gcc?  Could you list  
some of these

goals and explain how they relate to JIT?


Hi Dave,

I don't mean to invade into a pretty amusing thread, but I wanted to  
clarify one important thing: litjit and LLVM have nothing to do with  
each other.


libjit and LLVM have very different design points.  libjit is a bit  
more than a glorified macro assembler with some late "optimizations",  
whereas LLVM is a real compiler that happens to have the ability to  
emit machine code to memory.


To be perfectly clear, LLVM does not use libjit.

-Chris

[plugins]: Mainline merge @145344

2009-04-01 Thread Diego Novillo

I've merged mainline into plugins in preparation for a
plugins->mainline merge in the next few days.  I will start preparing
separate patches to simplify review.

Bootstrapped and tested on x86_64.


Diego.

Re: GCC + libJIT instead of LLVM

>>> It seems to
>>> me that LLVM solves many goals that are already complete and solved in
>>> GCC. So I think libJIT potentially is more useful for GCC and software
>>> developers.
>>
>> but you don't say what libjit would be more useful than, or how this
>> overlap
>> between "solved goals" between gcc and llvm implies that.  Do you simply
>> mean
>> that, because llvm and gcc both cover similar areas, and because libjit is
>> useful for llvm, it must also be useful for gcc?  Could you list some of
>> these
>> goals and explain how they relate to JIT?
>
> Hi Dave,
>
> I don't mean to invade into a pretty amusing thread, but I wanted to clarify
> one important thing: litjit and LLVM have nothing to do with each other.
>
> libjit and LLVM have very different design points.  libjit is a bit more
> than a glorified macro assembler with some late "optimizations", whereas
> LLVM is a real compiler that happens to have the ability to emit machine
> code to memory.
>
> To be perfectly clear, LLVM does not use libjit.
>
> -Chris

This is what Chris Lattner wrote a couple of years ago. Now I see an
exactly contradiction:

"

Hi All,

I was wondering what you could tell me about the differences in goals
between libjit and LLVM.  In particular, on this page:
http://www.southern-storm.com.au/doc/libjit/libjit_1.html

It is stated "Unlike other systems such as the JVM, .NET, Parrot, and
LLVM, libjit is not a virtual machine in its own right. It is the
foundation upon which a number of different virtual machines, dynamic
scripting languages, or customized rendering routines can be built."

I believe that the statement is true about .NET, JVM, and Parrot, but LLVM
is exactly what you describe: a framework that can be used to build a
number of different virtual machines.  In particular, LLVM assumes no
runtime model or library: we currently JIT C,C++,Stacker (a forth-like
language), and have good starts on Java, .NET, O-Caml, and Ruby
front-ends.

If you're not familiar with LLVM, it's actually a lot more than a JIT.
It's also a static, linktime, and offline optimizer that includes dozens
of aggressive SSA-based optimizations.  Another advantage of LLVM is that
it is mature and works well now.  :)  For more info, see:
http://llvm.cs.uiuc.edu/

Can you say a little bit about the advantages of using libjit over LLVM?
Also, can you please correct the quote above to accurately describe the
difference between libjit and LLVM?

Thanks,

-Chris

"

and
"
On Sunday 30 May 2004 12:46 pm, Chris Lattner wrote:

> What do you mean by "real" one?  They are both real.

"Real" in the sense that the other one is discontinued.  Which is essentially
what you want here: for libjit to be discontinued and turned into a thin C
API on top of LLVM.  That just isn't going to happen.  I'm just as attached
to my project as you are to yours.  Sorry.

> Sure, that's fine.  Please change the link to llvm.org though (a recent
> change).  Thanks!

I have updated the documentation in CVS and on the Web site.

Cheers,

Rhys.
"

There are also many other interesting things there:
http://lists.gnu.org/archive/html/dotgnu-libjit/2004-05/index.html

Thanks,
Kirill

Re: GCC + libJIT instead of LLVM

2009-04-01 Thread Manuel López-Ibáñez

2009/4/1 Kirill Kononenko :
>
> This is what Chris Lattner wrote a couple of years ago. Now I see an
> exactly contradiction:
>

Please, could you pinpoint side-by-side the two sentences that
contradict each other and later give links to (or quote) the context?
I am having troubling identifying the contradiction.

In any case, two years is a long time. Even if LLVM was using libjit
two years ago, it is pretty clear that LLVM is not using libjit
anymore. And that wouldn't be a contradiction.

As a general remark, I find your messages a bit vague and lacking
concreteness. Please take this as a constructive comment with the goal
of making easier: (1) for you to get your point across, and (2) for me
(and I guess others) to quickly understand your point. I think this
may be one reason why your messages are not being (generally) met with
the positive replies that you were surely expecting.

Cheers,

Manuel.

Re: GCC + libJIT instead of LLVM

2009-04-01 Thread Daniel Jacobowitz

On Wed, Apr 01, 2009 at 06:54:55PM +0200, Manuel López-Ibáñez wrote:
> 2009/4/1 Kirill Kononenko :
> >
> > This is what Chris Lattner wrote a couple of years ago. Now I see an
> > exactly contradiction:
> >
> 
> Please, could you pinpoint side-by-side the two sentences that
> contradict each other and later give links to (or quote) the context?
> I am having troubling identifying the contradiction.

Please, could you not do it on this list?

A discussion about the differences between LLVM and libjit is wildly
off-topic for GCC development.

-- 
Daniel Jacobowitz
CodeSourcery

missing return value

2009-04-01 Thread Paul Koning

The other day there was a request for a compile error if you do:

int foo(void) { }

and the answer was "the standard says that this is legal -- after all,
you can say 'foo();' so the return value isn't used and it doesn't
matter that it's missing".

That makes sense.

So how about:

   int foo (void) { }
   ...
   j = foo ();

This clearly *is* wrong.  The compiler may not always be able to
tell.  If it can -- for example, if this is inlined code where the
function definition is available at the time the call is compiled --
it sure would be helpful to have an error message here.

I just helped a colleague track one of these down after he had already
spent a day or three looking.  Bugs like this can be hard to spot.
Especially if, as in this case, you were dealing with a class wrapped
around another class, and the wrappers all look the same, and those
wrappers are where the problem lies.

 paul

Plugins & GGC ie GTY



Hello All,

[I don't know if this discussion belongs to gcc@ or gcc-patches@ so I'm 
sending it on gcc@ since I don't propose or discuss any code yet]


My understanding was that most plugins people are aware that somehow 
some plugins would need to have static GTY-ed roots for the GGC machinery.


So it seems to me that we'll need :

1. The ability to run gengtype in a special mode for plugins, on the 
source code of the plugin. to generate the gt-*.h files included by the 
source code of the plugin. This would require a patch to gengtype.


2. The ability to handle, very probably using dlsym, or perhaps by 
having a gcc_plugin_register_gty_table function called from the plugin 
initialization routine, to plug the generated root tables (an array of 
struct ggc_root_tab, which is defined in the generated gt-*.h files) of 
the plugin into the GGC machinery. This would require a short patch to 
ggc-common.c or similar ggc-*.c files.


Did I miss anything?

Regards.



PS. This is not an April Fool joke! I am quit serious about extra GTY-ed 
roots. It is for me an essential & required condition to perhaps 
transform the MELT branch into a mega-plugin.



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

Re: GCC + libJIT instead of LLVM

2009-04-01 Thread Daniel Berlin

On Wed, Apr 1, 2009 at 5:33 AM, Kirill Kononenko
 wrote:
> Hello Dear GCC Developers,
>
>
>
> I would like to ask your opinion about possibility for integration of
> the libJIT Just-In-Time compilation library and GCC. For example, the
> same way as libffi is integrated within gcc source tree. It seems to
> me that LLVM solves many goals that are already complete and solved in
> GCC. So I think libJIT potentially is more useful for GCC and software
> developers.
>
Highly disagree.

>
> What is your opinion about this idea? How this should be done and what
> improvements could be made to both libJIT and GCC for this kind of
> integration?

I don't think we should integrate libJIT into GCC. It doesn't solve
any of the *interesting* JIT problems we would have, it only solves
the ones we know how to solve in a fairly short time (given enough
developers).

Re: GCC + libJIT instead of LLVM

2009/4/1 Daniel Berlin :
> On Wed, Apr 1, 2009 at 5:33 AM, Kirill Kononenko
>  wrote:
>> Hello Dear GCC Developers,
>>
>>
>>
>> I would like to ask your opinion about possibility for integration of
>> the libJIT Just-In-Time compilation library and GCC. For example, the
>> same way as libffi is integrated within gcc source tree. It seems to
>> me that LLVM solves many goals that are already complete and solved in
>> GCC. So I think libJIT potentially is more useful for GCC and software
>> developers.
>>
> Highly disagree.
>
>>
>> What is your opinion about this idea? How this should be done and what
>> improvements could be made to both libJIT and GCC for this kind of
>> integration?
>
> I don't think we should integrate libJIT into GCC. It doesn't solve
> any of the *interesting* JIT problems we would have, it only solves

What are exactly the *interesting* JIT problems you have? And who are
exactly "we" again in this case? Is it Google? Or you personally speak
for all GCC user community?

> the ones we know how to solve in a fairly short time (given enough
> developers).

Do you actually have these extra 'enough developers'?




Thanks,
Kirill

Re: missing return value

2009-04-01 Thread Joe Buck

On Wed, Apr 01, 2009 at 10:18:32AM -0700, Paul Koning wrote:
> The other day there was a request for a compile error if you do:
> 
> int foo(void) { }
> 
> and the answer was "the standard says that this is legal -- after all,
> you can say 'foo();' so the return value isn't used and it doesn't
> matter that it's missing".

I think that the right answer to requests like this is to recommend
the use of -Wall, which will produce

foo.c:1: warning: control reaches end of non-void function

Those who want it to be an error can say "-Wall -Werror".

Re: generating functions and eh region

2009-04-01 Thread Vincent R.

On Wed, 01 Apr 2009 08:56:49 -0700, Ian Lance Taylor 
wrote:
> "Vincent R."  writes:
> 
>> Yes I think I don't explain things very clearly, so what is important to
>> know is that the __except keyword
>> can be passed instructions(case 1) or directly a function(case 2).
> 
> I see that but I don't see why it matters.
To me it seems important but I am not a gcc hacker

> 
> 
>> in the case 1)  ie if you declare something like :
>>
>> ...
>> __except( printf("hello gcc"), 1)
>>
>> and I look at asm generated I can notice that the instructions inside
the
>> patenthesis will be put inside a function
>> because I can notice a prologue and epilogue.
> 
> What asm are you looking at?
> 
The one in my previous email.

> gcc will do the right thing if you put statements in an exception
> region.

Hum how gcc can do that kind of things, is it some kind of voodoo ?
__except is not implemented yet and is more than a language construct
because it's an
OS thing. 
So maybe I need to say it once again, instructions inside __except needs to
be 
put inside a function by the compiler .
Let's imagine seh were designed differently, I mean for instance let's say
instead
of putting instructions in a function it would put ins directly without any
prologue and epilogue
would you still tell me that eh region will do what I need.
On what parameters does eh region choose to add or not epilogue/prologue ?
Or maybe we can pass some information to eh_region stuff to tell him it's a
function and in this case
I could understand that it's not magic.

Ok so now forget my previous questions, seh and so on.
I am going to express my problem differently, let's say I want to developp
a tool based on GCC
and used to tranform code. 

I mean it would parse source code and if it detects __transform keyword
make some tranformation, 
generate IL and then output the tranformed source code.
Original code is :

int main()
{
   __transform( printf("hello"); printf("world"), 10 );
}

and I would like to obtain

int main()
{
}

int func1()
{
  printf("hello"); 
  printf("world"); 
  return 10 
}

So my question is when parsing source code and when detetcing __transform
keyword you agree that 
I need to generate a function and put instructions in it.
So in this case should we use start_function ?
Don't tell me to use eh region or I am getting depressed.

Re: generating functions and eh region

"Vincent R."  writes:

>> gcc will do the right thing if you put statements in an exception
>> region.
>
> Hum how gcc can do that kind of things, is it some kind of voodoo ?
> __except is not implemented yet and is more than a language construct
> because it's an
> OS thing. 
> So maybe I need to say it once again, instructions inside __except needs to
> be 
> put inside a function by the compiler .

Can you explain why that is?  I don't know how SEH works; how does the
OS get involved?


> Let's imagine seh were designed differently, I mean for instance let's say
> instead
> of putting instructions in a function it would put ins directly without any
> prologue and epilogue
> would you still tell me that eh region will do what I need.

gcc supports C++ exceptions on all targets but does not put anything in
a function and does not use a separate prologue or epilogue.


> Ok so now forget my previous questions, seh and so on.
> I am going to express my problem differently, let's say I want to developp
> a tool based on GCC
> and used to tranform code. 
>
> I mean it would parse source code and if it detects __transform keyword
> make some tranformation, 
> generate IL and then output the tranformed source code.
> Original code is :
>
> int main()
> {
>__transform( printf("hello"); printf("world"), 10 );
> }
>
> and I would like to obtain
>
> int main()
> {
> }
>
> int func1()
> {
>   printf("hello"); 
>   printf("world"); 
>   return 10 
> }
>
> So my question is when parsing source code and when detetcing __transform
> keyword you agree that 
> I need to generate a function and put instructions in it.
> So in this case should we use start_function ?
> Don't tell me to use eh region or I am getting depressed.

It seems to me that you would want to treat it as a nested function.
So, yes, you should use start_function.  See
c_parser_declaration_or_fndef when nested is true.  If the code inside
__transform is not permitted to refer to variables defined in main, then
you might need to do some additional work to prevent that from
happening.

Ian

Re: Plugins & GGC ie GTY

On Wed, Apr 1, 2009 at 7:22 PM, Basile STARYNKEVITCH
 wrote:
>
> Hello All,
>
> [I don't know if this discussion belongs to gcc@ or gcc-patches@ so I'm
> sending it on gcc@ since I don't propose or discuss any code yet]
>
> My understanding was that most plugins people are aware that somehow some
> plugins would need to have static GTY-ed roots for the GGC machinery.
>
> So it seems to me that we'll need :
>
> 1. The ability to run gengtype in a special mode for plugins, on the source
> code of the plugin. to generate the gt-*.h files included by the source code
> of the plugin. This would require a patch to gengtype.
>
> 2. The ability to handle, very probably using dlsym, or perhaps by having a
> gcc_plugin_register_gty_table function called from the plugin initialization
> routine, to plug the generated root tables (an array of struct ggc_root_tab,
> which is defined in the generated gt-*.h files) of the plugin into the GGC
> machinery. This would require a short patch to ggc-common.c or similar
> ggc-*.c files.
>
> Did I miss anything?

Plugins shouldn't keep permanent references to GCed memory.  At least
that would make it unnecessary to do what you suggest.

Richard.

Re: [plugins]: Mainline merge @145344

2009-04-01 Thread Diego Novillo

On Wed, Apr 1, 2009 at 12:19, Diego Novillo  wrote:
> I've merged mainline into plugins in preparation for a
> plugins->mainline merge in the next few days.  I will start preparing
> separate patches to simplify review.

A clarification.  I don't intend to do the actual merge into mainline
until the new license wording has been committed.

Diego.

Re: Plugins & GGC ie GTY


Richard Guenther wrote:



Plugins shouldn't keep permanent references to GCed memory.  At least
that would make it unnecessary to do what you suggest.



I strongly disagree with that, and I simply do not understand your 
position. In my perception, plugins are essentially loaded (dlopen-ed) 
but never unloaded (dlclose-ed; perhaps they would be dlclose-ed when 
every thing is done). Why should they not use any GTY stuff? What makes 
you think that some features of GCC (like GTY ...) are invalid inside 
plugins?


I find your position as extreme as saying: plugins should never call 
malloc or xcalloc, or should never call warning_at, or should never call 
XXX! Why?


So what are plugins for?

Regards.

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

Call for testers: MPC-0.6 released


Thanks to everyone who tested the prerelease snashot of MPC.  The
maintainers have now released mpc-0.6 which incorporates hopefully
everyone's feedback and testing results.

http://lists.gforge.inria.fr/pipermail/mpc-discuss/2009-April/000176.html

The MPC developers have made a concerted effort to align their "supported
platforms" list with that of GCC.  So hopefully all the primary and
secondary GCC release criteria platforms now work out of the box.  Please
get the tarball and report test results to the mpc forum.

http://www.multiprecision.org/mpc/index.php?content=platforms

The MPC developers have commited to making a quick 0.6.1 release that
addresses any remaining problems on platforms important to GCC.  I'm 
especially interested in seeing test results for non-linux-gnu, though any 
test results are appreciated especially if your platform is on the GCC 
criteria list.


http://gcc.gnu.org/gcc-4.5/criteria.html

   Thanks,
   --Kaveh
--
Kaveh R. Ghazi

Need Help with downloading gcc binaries for x86 Atom Processor for CentOS.

2009-04-01 Thread Kesari Reddy


Hi,

My name is Mallik and I work for Sun.  I need a favor from you.  I need 
to cross compile our product to work on x86 Atom Processor on CentOS.  
Could you please point me to the link where I can download the gcc 
binaries.  I downloaded the source from ix86/gcc-4_4-branch but facing 
some problems building it.  I wasn't able to configure it.  I thought if 
I get the binaries that would help.


Please help me.

Thanks,
Mallik.
510-299 6629.

Re: GCC + libJIT instead of LLVM

Please, let collect together all useful ideas and concrete thoughts? I
am sure many people already have thought about which JITing support
GCC users need. I also do have my thoughts about this research topic
but I would like also to have useful feedback from people who also
understand this research topic like me and gcc internals. Please also
stop flaming about LLVM.



Thanks,
Kirill


2009/4/1 Kirill Kononenko :
> 2009/4/1 Daniel Berlin :
>> On Wed, Apr 1, 2009 at 5:33 AM, Kirill Kononenko
>>  wrote:
>>> Hello Dear GCC Developers,
>>>
>>>
>>>
>>> I would like to ask your opinion about possibility for integration of
>>> the libJIT Just-In-Time compilation library and GCC. For example, the
>>> same way as libffi is integrated within gcc source tree. It seems to
>>> me that LLVM solves many goals that are already complete and solved in
>>> GCC. So I think libJIT potentially is more useful for GCC and software
>>> developers.
>>>
>> Highly disagree.
>>
>>>
>>> What is your opinion about this idea? How this should be done and what
>>> improvements could be made to both libJIT and GCC for this kind of
>>> integration?
>>
>> I don't think we should integrate libJIT into GCC. It doesn't solve
>> any of the *interesting* JIT problems we would have, it only solves
>
> What are exactly the *interesting* JIT problems you have? And who are
> exactly "we" again in this case? Is it Google? Or you personally speak
> for all GCC user community?
>
>> the ones we know how to solve in a fairly short time (given enough
>> developers).
>
> Do you actually have these extra 'enough developers'?
>
>
>
>
> Thanks,
> Kirill
>

Re: Deprecating Itanium1 for GCC 4.4

2009-04-01 Thread Steven Bosscher

On Sun, Mar 29, 2009 at 4:46 PM, Joseph S. Myers
 wrote:
> On Sun, 29 Mar 2009, Steven Bosscher wrote:
>
>> On Mon, Mar 23, 2009 at 7:28 PM, Steve Ellcey  wrote:
>> > I think
>> > depreciating Itanium1 tuning for 4.4 and removing it in 4.5 is
>> > reasonable.  Code generated and tuned for Itanium2 should run fine on
>> > Itanium1 (Merced).  It won't be scheduled optimally of course, but it
>> > should run correctly.
>> (...)
>> > I will approve this patch, but it should say "Itanium1 tuning support"
>> > or something like that.  The code will run on Itanium1, just not
>> > optimally.
>>
>> Like so (with same changelog).  I'll commit this before the end of the
>> week to the gcc-4_4-branch if no-one objects. Bootstrapped and tested
>> on ia64 with gcc-4_4-branch.
>>
>> For gcc 4.5, should I wait with posting the cleanup patch until the
>> end of the development cycle, or can we go ahead and clean things up
>> now in stage 1?
>
> If the cleanup doesn't go on trunk at the same time as the deprecation
> patch goes on 4.4, the deprecation patch should go on trunk at that time
> until the cleanup is done, to avoid this being deprecated only on 4.4.  (I
> think early stage 1 is a fine time for doing the cleanup.)

Okeydokey.  I've put the patch with the notification on trunk and on
the 4.4 branch. I have also added a note to the web pages (see below).
 I'll work on cleaning up the Itanium1 bits asap.

Ciao!
Steven

Index: changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.4/changes.html,v
retrieving revision 1.64
diff -u -r1.64 changes.html
--- changes.html1 Apr 2009 06:17:44 -   1.64
+++ changes.html1 Apr 2009 19:52:41 -
@@ -98,6 +98,8 @@
   2BSD on PDP-11 (pdp11-*-bsd)
   AIX 4.1 and 4.2 on PowerPC (rs6000-ibm-aix4.[12]*,
 powerpc-ibm-aix4.[12]*)
+  Tuning support for Itanium1 (Merced) variants.  Note that
+Code tuned Itanium2 should also run correctly on Itanium1.

Re: missing return value

2009-04-01 Thread Paul Koning

> "Joe" == Joe Buck  writes:

 Joe> On Wed, Apr 01, 2009 at 10:18:32AM -0700, Paul Koning wrote:
 >> The other day there was a request for a compile error if you do:
 >> 
 >> int foo(void) { }
 >> 
 >> and the answer was "the standard says that this is legal -- after
 >> all, you can say 'foo();' so the return value isn't used and it
 >> doesn't matter that it's missing".

 Joe> I think that the right answer to requests like this is to
 Joe> recommend the use of -Wall, which will produce

 Joe> foo.c:1: warning: control reaches end of non-void function

 Joe> Those who want it to be an error can say "-Wall -Werror".

You're right, thanks.

I thought we had that turned on everywhere but it turned out that
wasn't the case.

   paul

Re: Call for testers: MPC-0.6 released

On Wed, Apr 1, 2009 at 8:42 PM, Kaveh R. Ghazi  wrote:
> Thanks to everyone who tested the prerelease snashot of MPC.  The
> maintainers have now released mpc-0.6 which incorporates hopefully
> everyone's feedback and testing results.
>
> http://lists.gforge.inria.fr/pipermail/mpc-discuss/2009-April/000176.html
>
> The MPC developers have made a concerted effort to align their "supported
> platforms" list with that of GCC.  So hopefully all the primary and
> secondary GCC release criteria platforms now work out of the box.  Please
> get the tarball and report test results to the mpc forum.
>
> http://www.multiprecision.org/mpc/index.php?content=platforms
>
> The MPC developers have commited to making a quick 0.6.1 release that
> addresses any remaining problems on platforms important to GCC.  I'm
> especially interested in seeing test results for non-linux-gnu, though any
> test results are appreciated especially if your platform is on the GCC
> criteria list.
>
> http://gcc.gnu.org/gcc-4.5/criteria.html

I get 1 failure on linux-{i586,x86_64,ppc,ppc64,ia64,s390,s390x} platforms:

inp_str.c:131: MPC assertion failed: n == nread
/bin/sh: line 4:  2347 Aborted (core dumped) ${dir}$tst
FAIL: tio_str

Richard.

>       Thanks,
>       --Kaveh
> --
> Kaveh R. Ghazi
>
>

Re: Call for testers: MPC-0.6 released


From: "Richard Guenther" 


I get 1 failure on linux-{i586,x86_64,ppc,ppc64,ia64,s390,s390x} 
platforms:


inp_str.c:131: MPC assertion failed: n == nread
/bin/sh: line 4:  2347 Aborted (core dumped) ${dir}$tst
FAIL: tio_str

Richard.


Thanks for the thorough testing!

I don't get this testsuite failure in the compile farm on e.g. gcc14 
(x86_64-linux-gnu) and I assume neither did any of the MPC developers on 
their personal dev boxes.  So let's try and narrow down the difference in 
your environment.


Can you please tell me the versions you used for gcc, gmp, mpfr and the 
linux distro?


For reference I used gcc-4.1.2, gmp-4.2.2, mpfr-2.3.2 and Debian GNU/Linux:
Linux gcc14 2.6.18-6-vserver-amd64 #1 SMP Fri Dec 12 06:15:44 UTC 2008 
x86_64 GNU/Linux


   Thanks,
   --Kaveh

Re: Call for testers: MPC-0.6 released

On Wed, Apr 1, 2009 at 10:36 PM, Kaveh R. Ghazi  wrote:
> From: "Richard Guenther" 
>>
>> I get 1 failure on linux-{i586,x86_64,ppc,ppc64,ia64,s390,s390x}
>> platforms:
>>
>> inp_str.c:131: MPC assertion failed: n == nread
>> /bin/sh: line 4:  2347 Aborted                 (core dumped) ${dir}$tst
>> FAIL: tio_str
>>
>> Richard.
>
> Thanks for the thorough testing!
>
> I don't get this testsuite failure in the compile farm on e.g. gcc14
> (x86_64-linux-gnu) and I assume neither did any of the MPC developers on
> their personal dev boxes.  So let's try and narrow down the difference in
> your environment.
>
> Can you please tell me the versions you used for gcc, gmp, mpfr and the
> linux distro?
>
> For reference I used gcc-4.1.2, gmp-4.2.2, mpfr-2.3.2 and Debian GNU/Linux:
> Linux gcc14 2.6.18-6-vserver-amd64 #1 SMP Fri Dec 12 06:15:44 UTC 2008
> x86_64 GNU/Linux

I tested on openSUSE Factory which currently has gcc 4.3.3, gmp 4.2.3,
mpfr 2.4.1 and some pre-2.10 glibc.

Richard.

>       Thanks,
>       --Kaveh
>
>

Re: Plugins & GGC ie GTY

Basile STARYNKEVITCH wrote:

Richard Guenther wrote:

Plugins shouldn't keep permanent references to GCed memory. At least
that would make it unnecessary to do what you suggest.

I strongly disagree with that, and I simply do not understand your
position. In my perception, plugins are essentially loaded (dlopen-ed)
but never unloaded (dlclose-ed; perhaps they would be dlclose-ed when
every thing is done). Why should they not use any GTY stuff? What
makes you think that some features of GCC (like GTY ...) are invalid
inside plugins?

I find your position as extreme as saying: plugins should never call
malloc or xcalloc, or should never call warning_at, or should never
call XXX! Why?

So what are plugins for?

I really think we should provide some usage scenarios for plugins.

For argumenting GTY-ed static data in plugins, I would just mention some of the
reasons GTY-ed data are already used in GCC.

First, most of us do know that a real garbage collector is the only way to
manage complex data structures (with circularities, many kind of cross
references, complex reference graph, ...). There is a reason why Lisp, Java,
ML, ... have garbage collectors for several dozens of year, and GCC is becoming
such a complex beast that GC is unavoidable.
[BTW, I am surprised that while some people are advocating recoding GCC in C++,
nobody suggested to recode it in Java or C#]

And if garbage collection is avoidable in GCC, given the strong opposition it has, all
the GTY & gengtype stuff would have been removed by now. The mere fact it is
staying here is in my opinion very significant. If GC was not relevant in GCC, GGC
& GTY would have gone long time ago. They didn't!

I find the mere fact that nobody bothered to remove GTY & gengtype from GCC significant,
even if many people (me including) don't like very much the GGC implementation (I would
prefer a systematic way of using a GC, and a rule as strong as "nobody delete data"
except the garbage collector. I do admit that I am quite extremist on memory management. But
memory management are non-modular issues: they are whole program features!).

To be more specific and concrete, many passes use GTY-ed data. It seems that the common scenario is to have some data built in one pass and reused in some other passes. Then there is no easy way to find out who would delete the data,

Now, I don't see why a plugin won't fall in that "pattern". Definitely, some
guy would want to code a plugin which provides eg two or three (not only one) passes in
GCC, all related in the sense that they would operate on some common data. Here a garbage
collector makes sense, and having some GTY-ed data (or a vector) inside a plugin is
definitely relevant.

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

Re: Call for testers: MPC-0.6 released


From: "Richard Guenther" 


I tested on openSUSE Factory which currently has gcc 4.3.3, gmp 4.2.3,
mpfr 2.4.1 and some pre-2.10 glibc.


I tried with vanilla mpfr-2.4.1 and gmp-4.2.3, and mpc still passed all it's 
tests on gcc14.  Would it be fair to suspect something in your prerelease 
glibc?  Can you please help track it down?


Thanks,
--Kaveh

Re: Call for testers: MPC-0.6 released

On Wed, Apr 1, 2009 at 11:03 PM, Kaveh R. Ghazi  wrote:
> From: "Richard Guenther" 
>
>> I tested on openSUSE Factory which currently has gcc 4.3.3, gmp 4.2.3,
>> mpfr 2.4.1 and some pre-2.10 glibc.
>
> I tried with vanilla mpfr-2.4.1 and gmp-4.2.3, and mpc still passed all it's
> tests on gcc14.  Would it be fair to suspect something in your prerelease
> glibc?  Can you please help track it down?

Same behavior with openSUSE 11.1 (glibc 2.9, gcc 4.3.2, gmp 4.2.3, mpfr 2.3.2).

Note that I build with -D_FORTIFY_SOURCE=2 -fstack-protector.

Richard.

Re: Call for testers: MPC-0.6 released

2009-04-01 Thread Janis Johnson

On Wed, 2009-04-01 at 23:21 +0200, Richard Guenther wrote:
> On Wed, Apr 1, 2009 at 11:03 PM, Kaveh R. Ghazi  
> wrote:
> > From: "Richard Guenther" 
> >
> >> I tested on openSUSE Factory which currently has gcc 4.3.3, gmp 4.2.3,
> >> mpfr 2.4.1 and some pre-2.10 glibc.
> >
> > I tried with vanilla mpfr-2.4.1 and gmp-4.2.3, and mpc still passed all it's
> > tests on gcc14.  Would it be fair to suspect something in your prerelease
> > glibc?  Can you please help track it down?
> 
> Same behavior with openSUSE 11.1 (glibc 2.9, gcc 4.3.2, gmp 4.2.3, mpfr 
> 2.3.2).
> 
> Note that I build with -D_FORTIFY_SOURCE=2 -fstack-protector.

I get the failure Richard mentioned when I use -D_FORTIFY_SOURCE=2
-fstack-protector but no failures without those options.  This is on
powerpc64-linux (but defaulting to -m32) with:

RHEL 5.3
GCC 4.3.2
GMP 4.2.4
MPFR 2.4.1
MPC 0.6

I don't normally use those options.

Janis

Re: Plugins & GGC ie GTY

> And if garbage collection is avoidable in GCC, given the strong opposition it 
> has, all the GTY & gengtype stuff would have been removed by now. The mere 
> fact it is staying here is in my opinion very significant. If GC was not 
> relevant in GCC, GGC & GTY would have gone long time ago. They didn't!

I believe it is avoidable, but:
- There is no consensus that it should be avoided, and there are more
  important issues to discuss.
- Even if there was a consensus to avoid it, nobody is willing to but in
  the time to change gcc and keep it leak-free (or merely keep memory leaks
  at a level comparable to GGC memory overhead).

> To be more specific and concrete, many passes use GTY-ed data. It seems that 
> the common scenario is to have some data built in one pass and reused in some 
> other passes. Then there is no easy way to find out who would delete the data,
> 
> Now, I don't see why a plugin won't fall in that "pattern". Definitely, some 
> guy would want to code a plugin which provides eg two or three (not only one) 
> passes in GCC, all related in the sense that they would operate on some 
> common data. Here a garbage collector makes sense, and having some GTY-ed 
> data (or a vector) inside a plugin is definitely relevant.

As long as you only need to GTY known types, you can avoid having extra GTY
roots by having all plugins share one GTY root in the plugin infrastructure;
this root can point to a list to which each plugin can add at will.

If you want new types, it gets ugly, because how can you independently
develop plugins and avoid collisions?  An enum to describe a type
won't be enough anymore, unless you want to go te a really silly width and
statart doling out namespaces.

You could approach it a bit more object-oriented and have a pointer in
each object that points to a descriptor for the type.
If you define such a type in the plugin infrastructure, it again becomes
a special kind of pre-defined type.
I suppose the main work will be to get the GTY parser to create the
type descriptors for custom types in modules. 
This e-mail was sent from a group e-mail system of ARC International Plc. Full 
details of the registered names and addresses of companies within the ARC group 
can be found on the ARC website.ARC International plc, Registered Office: 
Verulam Point, Station WaySt. Albans AL1 5HE United Kingdom Registered in 
England and Wales No.  3592130savm-exch03

Re: Plugins & GGC ie GTY

2009-04-01 Thread Steven Bosscher

On Thu, Apr 2, 2009 at 12:48 AM, Joern Rennecke  wrote:
>> And if garbage collection is avoidable in GCC, given the
>> strong opposition it has, all the GTY & gengtype stuff would
>> have been removed by now.

This looks like a rather uninformed opinion...

>> The mere fact it is staying here is
>> in my opinion very significant. If GC was not relevant in GCC,
>> GGC & GTY would have gone long time ago. They didn't!

Welcome... to the desert.. of the Real.

Once something is in GCC, it is near impossible to get it out again.
In this case, the "something" is PCH, which still heavily depends on
GGC.  That does *not* mean everyone (or even a majority) likes it.

And more importantly for this discussion: It also doesn't mean that
other, new infrastructure should increases GCC's dependency on the GGC
stuff.

> I believe it is avoidable, but:
> - There is no consensus that it should be avoided, and there are more
>  important issues to discuss.

Exactly!

Actually, I think there is more-or-less consensus that it should be
avoided if possible.  The current GTY machinery forces *everything*
into GC memory, mostly just to avoid broken PCH.  But that is a
problem with the design/implementation of the GGC stuff, not
necessarily with the concept (obstacks and pools are also not all
that...).

Some examples: RTL *must* live in GGC memory only for PCH.  Likewise
with alias set, and most static global variables decorated with a GTY
marker.  I don't think anyone really likes that.  I also don't think
anyone is really sure what should be decorated with a GTY marker and
what can safely be left undecorated (nobody ever un-decorated anything
after the tree-ssa merge, though I would expect some markers are
redundant now).

> - Even if there was a consensus to avoid it, nobody is willing to but in
>  the time to change gcc and keep it leak-free (or merely keep memory leaks
>  at a level comparable to GGC memory overhead).

This is easier nowadays than it used to be, when GCC switched from
obstacks to garbage collection.  Tools like valgrind make life a tad
less unfriendly for the debugger.  But yes, +1.

>> To be more specific and concrete, many passes use GTY-ed
>> data. It seems that the common scenario is to have some
>> data built in one pass and reused in some other passes.

I don't see this scenario really.  There is (should be?) almost no
data transfer between passes (except the intermediate representation,
which obviously has a special position in this discussion).

>> Then there is no easy way to find out who would delete
>> the data,

So Don't Do That (tm).

>> Now, I don't see why a plugin won't fall in that "pattern".
>> Definitely, some guy would want to code a plugin which
>> provides eg two or three (not only one) passes in GCC,

And use other types than the types already in GCC itself, and hand
that data over across a gcc_collect call?  Sounds broken by design to
me.  At least, I don't think that works for any pass even within GCC
itself, so why should it work for plugins?

You should not pass data from one pass to another via GC memory,
except the call graph and everything that hangs from there (cgraph ->
functions -> cfg -> stmts -> operands).  As long as you only modify
the existing intermediate representation, you don't have to worry
about GGC at all!

To me, it seems that plugins should be sufficiently self-contained to
take care of their own memory management, *without* GGC, except for
data that is shared between the plugin and the compiler proper (i.e.
the cgraph, etc.).

But you seem to imply that your plugin needs to do more than that...?

> As long as you only need to GTY known types, you can avoid having extra GTY
> roots by having all plugins share one GTY root in the plugin infrastructure;
> this root can point to a list to which each plugin can add at will.

I don't think this would work.  The marker routines wouldn't know what
would be in this one root with new types.  But, as you said...

> If you want new types, it gets ugly,

...there's an understatement!

>because how can you independently
> develop plugins and avoid collisions?  An enum to describe a type
> won't be enough anymore, unless you want to go te a really silly width and
> statart doling out namespaces.

Exactly.

How would you write the markers and how would you let the GTY
mechanism know which markers to call??  This is all automatically
generated from the GCC source now, but I don't see how that woudl work
with plugins unless you build the plugin along with GCC (and thereby
defeat the purpose of plugins).  Write them by hand?  More power to
you if you even think you *can* do that.

Ciao!
Steven

Re: Call for testers: MPC-0.6 released


From: "Janis Johnson" 

Same behavior with openSUSE 11.1 (glibc 2.9, gcc 4.3.2, gmp 4.2.3, mpfr 
2.3.2).


Note that I build with -D_FORTIFY_SOURCE=2 -fstack-protector.


I get the failure Richard mentioned when I use -D_FORTIFY_SOURCE=2
-fstack-protector but no failures without those options.  This is on
powerpc64-linux (but defaulting to -m32) with:

RHEL 5.3
GCC 4.3.2
GMP 4.2.4
MPFR 2.4.1
MPC 0.6

I don't normally use those options.
Janis


Ah, that helps.  I was able to reproduce the failure using 
just -D_FORTIFY_SOURCE=2.  However when I used both -D_FORTIFY_SOURCE=2 
*and* -fstack-protector the error went away again.


I'm using gcc-4.1.2 if that matters, perhaps there's a bug 
in -fstack-protector in that version that masks this.


Anyway, thanks both of you for helping to track it down.  I'll forward this 
along to the MPC maintainers.


--Kaveh

Re: Revised GCC Runtime Library Exception

2009-04-01 Thread Joe Buck

On Wed, Apr 01, 2009 at 06:48:17AM -0700, Joern Rennecke wrote:
> Say you have module A, B, C and D.  A is the main program and uses B, C
> and D.  B uses the runtime library, and is therefore an independent module.
> Thus, you are allowed to link B with the runtime library.  An argument
> could be made that A is an independent module because it depends on B,
> although that seems a bit risky to bet a companies fortunes on.
> At any rate C and D are not independent modules, because they don't need
> the runtime library.  Hence you are only allowed to convey a work of Target
> Code comprising A, B, C and D together with (parts of) the Runtime Library
> under the terms of the GPL, if at all.

We brought up that point, and the resolution will be that the FSF will
publish an FAQ explicitly blessing this case.  Their argument is that we
don't need to change the text because {A,B,C,D} together can be treated as
an independent module, and if you have C and D alone, they don't need the
library or the exception.  I understand your reading as well, and I argued
for clearer text, but the people at the SFLC with the law degrees think
it's fine.

Since the FSF is the copyright owner, even if your reading is held by
someone to be correct, then the FSF's FAQ would count as an additional
permission.

I've seen drafts of the FAQ; we'll push them to publish it.

Re: Call for testers: MPC-0.6 released

2009-04-01 Thread Marc Glisse


On Wed, 1 Apr 2009, Kaveh R. Ghazi wrote:

Ah, that helps.  I was able to reproduce the failure using just 
-D_FORTIFY_SOURCE=2.  However when I used both -D_FORTIFY_SOURCE=2 *and* 
-fstack-protector the error went away again.


I'm using gcc-4.1.2 if that matters, perhaps there's a bug in 
-fstack-protector in that version that masks this.


Anyway, thanks both of you for helping to track it down.  I'll forward this 
along to the MPC maintainers.


This could be related to a call to sprintf(str,...,str,...), which 
according to the doc is undefined behaviour.


--
Marc Glisse

Re: Plugins & GGC ie GTY


Hello All


Joern Rennecke wrote:



As long as you only need to GTY known types, you can avoid having extra GTY
roots by having all plugins share one GTY root in the plugin infrastructure;
this root can point to a list to which each plugin can add at will.

If you want new types, it gets ugly, because how can you independently
develop plugins and avoid collisions?  An enum to describe a type
won't be enough anymore, unless you want to go te a really silly width and
statart doling out namespaces.

  
We don't need any enum to describe the type, unless the new type is 
added into existing ones.


To be more concrete, let's suppose at first that a plugin FOO, which is 
loaded by dlopen-ing FOO.so, uses GTY for some static roots. For 
simplication assume FOO is only one C source file FOO.c which contains 
therefore something like


struct someFOOstruct_st GTY(()) {
};

static GTY(()) struct someFOOstruct_st *someFOOptr;

...
#include "gt-FOO.h"

Now, I assume gengtype has been hacked to generate gt-FOO.h correctly 
from FOO.c. I hope that is not an impossible hypothesis [1].


The generated file gt-FOO.h contains something like

const struct ggc_root_tab gt_ggc_r_gt_FOO_h[] = {...}

We just have to add some small code [2] into the ggc_mark_roots routine 
of gcc/ggc-common.c to add the scanning using this gt_ggc_r_gt_FOO_h. 
This is not a big deal. We should simply add a routine 
ggc_register_plugin_root_tab(const struct ggc_root_tab*) that adds its 
argument to some (static variable in gcc/ggc-common.c which is a) linked 
list or vector, and have ggc_mark_root scan that list or vector by 
adding a few lines there. We require plugin initializers to call 
ggc_register_plugin_root_tab appropriatly, exactly like they do already 
call register_callback etc...


Now there is the precompiled header issue. As an important remark, PCH 
are not stable from one minor version of GCC to another (eg 4.3.1 to 
4.3.2). As another remark, PCH are not very used. So my first attitude 
would be simply that: any compilation involving a plugin cannot use or 
generate any precompiled header. And PCH and plugins are already messy, 
even without any additional GTY-ed roots, for the simple reason that 
plugins are adding new code (the dlopen-ed one) into GCC whose behavior 
is altered by the plugin.


If we really care about PCH with plugins (I really think we should not 
care that much initially and leave the subject to future work), we 
should write in the PCH file the full list of all the plugins, probably 
their crypto-checksum (like md5 or sha1) to be sure that the plugin 
loaded again is exactly the same as the plugin which was active when 
generating the PCH, etc...


I believe we should not care about PCH and plugins at first, 
independently of any GTY in plugins.



==

Note [1]: the generated gt-FOO.h depends mostly of FOO.c, not of much 
else. There is indeed some generated code (specific to each GTY-ed 
struct) in gtype-desc.c, and we have to figure out how to generate it 
inside gt-FOO.h (or maybe another plugin specific generated file like 
gt2-FOO.h) and use it in plugins context. In gtype-desc.c there is 
another  struct ggc_root_tab gt_ggc_r_gtype_desc_c which we have to 
somehow make more dynamic (I don't know how exactly yet), and also the 
rtx_next array. Maybe we have to change the RTX_NEXT macro in rtl.h (but 
I don't know what this macro is for).


Note [2]: the code to add into ggc_mark_roots is quite similar to 
http://gcc.gnu.org/ml/gcc-patches/2009-01/msg00431.html; not a big deal, 
very probably less than 50 lines.


=


I don't claim to have figured out all the details, but I don't see what is very 
difficult in adding GTY-ed stuff in plugins (this is a feature
I really need to make MELT becoming a plugin) provided of course we
don't care yet about PCH & plugins, which is a difficult subject by
itself (even without any GTY inside plugins).




Comments (especially constructive comments) are welcome

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

Re: stdint.h type information needed