Tom Tromey writes:
>
> Java is fairly dynamic, as I'm sure you know. So, I'm much more
> interested in the JITting possibilities than in link time
> optimizations; the latter is cool and probably useful to embedded
> users of gcj, but I'd imagine for all our recent binary compatibility
> de
> "Chris" == Chris Lattner <[EMAIL PROTECTED]> writes:
Chris> In this role, it provides a static optimizer, interprocedural link-
Chris> time optimizer, JIT support, and several other features.
I'm quite interested in the JIT aspect of LLVM, for gcj.
This would fill one of our major missing g
> "Chris" == Chris Lattner <[EMAIL PROTECTED]> writes:
>> Only the Ada frontend seems to be in a state to maybe support direct
>> frontend IR to LLVM translation.
Chris> Sure, also maybe Fortran?
FWIW gcjx was designed to make this easy to do. And just yesterday a
volunteer started working
I think that a VM such as this should also be able to implement some basic
atomic operations such as atomic add and/or compare and swap.
On Tue, 22 Nov 2005, Joseph S. Myers wrote:
On Sat, 19 Nov 2005, Chris Lattner wrote:
This is a direct result of the representation that you are proposing to use
for IPA. LLVM is *always* capable of merging two translation units correctly,
So compilation options which change the semantics o
On Sat, 19 Nov 2005, Chris Lattner wrote:
> This is a direct result of the representation that you are proposing to use
> for IPA. LLVM is *always* capable of merging two translation units correctly,
So compilation options which change the semantics of GIMPLE are translated
into local flags on
Daniel Berlin wrote:
>
> The bottom line is that personally, I'm not in love with tree-ssa or my
> code enough that I think ego should stand in the way of GCC making the
> right decision. I would hope others who have written the "shiny new
> tree optimizers" feel the same way.
>
Seconded. I
On Sunday 20 November 2005 00:49, Chris Lattner wrote:
> On Sun, 20 Nov 2005, Steven Bosscher wrote:
> > On Saturday 19 November 2005 18:56, Chris Lattner wrote:
> >>> Only the Ada frontend seems to be in a state to maybe support direct
> >>> frontend IR to LLVM translation.
> >>
> >> Sure, also ma
On Sun, 20 Nov 2005, Steven Bosscher wrote:
Can you explain what you mean?
I mean it would take a complete re-write of the translation phase from
gfortran's native program representation to GENERIC trees. Even if it
is "quite possible" to make it write out LLVM directly, it would be a
huge job
On Sunday 20 November 2005 01:49, Chris Lattner wrote:
> On Sun, 20 Nov 2005, Steven Bosscher wrote:
> > On Saturday 19 November 2005 18:56, Chris Lattner wrote:
> >>> Only the Ada frontend seems to be in a state to maybe support direct
> >>> frontend IR to LLVM translation.
> >>
> >> Sure, also ma
On Sun, 20 Nov 2005, Steven Bosscher wrote:
On Saturday 19 November 2005 18:56, Chris Lattner wrote:
Only the Ada frontend seems to be in a state to maybe support direct
frontend IR to LLVM translation.
Sure, also maybe Fortran?
I wouldn't count on it...
Can you explain what you mean? The
On Saturday 19 November 2005 18:56, Chris Lattner wrote:
> > Only the Ada frontend seems to be in a state to maybe support direct
> > frontend IR to LLVM translation.
>
> Sure, also maybe Fortran?
I wouldn't count on it...
Gr.
Steven
On 11/19/05, Joseph S. Myers <[EMAIL PROTECTED]> wrote:
> On Fri, 18 Nov 2005, Chris Lattner wrote:
>
> > 1. The build system is taught about C++ code.
>
> With toplevel bootstrap this will bootstrap libstdc++ so that the compiler
> ends up linked with the new libstdc++ not the (in general
> ABI-in
Kenneth Zadeck writes:
This quickly becomes
difficult and messy, which is presumably why the link-time proposal
allows the linker to "give up" linking two translation units.
The reason for the complexity of the type system handling in our
proposal was motivated primarily by two concerns:
1)
> Specifically, advocates of the recent link-time-optimization proposal
> [1] may claim that exposing all of the information that DWARF captures
> (e.g. about the type system) at link-time is a good thing: it makes it
> easier to do specific high-level optimizations, because all of the
> info
On Sat, 19 Nov 2005, Joseph S. Myers wrote:
On Fri, 18 Nov 2005, Chris Lattner wrote:
1. The build system is taught about C++ code.
With toplevel bootstrap this will bootstrap libstdc++ so that the compiler
ends up linked with the new libstdc++ not the (in general
ABI-incompatible) old one? (
Richard Guenther writes:
I would propose to even think of doing only IPO at LLVM and go back to
gimple for the rest of the tree-ssa pipeline. At least that should be
possible. Would we get link-time optimization this way, or is the LLVM
link-time optimization architected differently?
Sure,
On Fri, 18 Nov 2005 17:50:52 -0800, Chris Lattner wrote:
> Recently, at Apple, I have been working on a new version of the llvm-
> gcc translation layer, built on GCC 4 ... I plan to have this work
> committed to the Apple branch within a month.
I'm curious as to why Apple is doing this. Is it s
On Fri, 18 Nov 2005, Chris Lattner wrote:
> 1. The build system is taught about C++ code.
With toplevel bootstrap this will bootstrap libstdc++ so that the compiler
ends up linked with the new libstdc++ not the (in general
ABI-incompatible) old one? (This question applies to all projects
invo
On 11/19/05, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:
> On Fri, Nov 18, 2005 at 05:50:52PM -0800, Chris Lattner wrote:
> > * This will not support !
> >
> > As describe above, we won't support every target that GCC currently
> > does. Three options are possible:
> >
> > 1. We (the GCC communit
> (B) What bits of GCC would we be bypassing, and how badly would we miss
> them?
>
> Presumably, many of the shiny new tree optimizers. Ow. But GCC was
> not in any state to do this sort of surgery a year ago, I think.
>
Probably true on both counts, but that wouldn't bother me, speaking as
s
Daniel Jacobowitz writes:
As describe above, we won't support every target that GCC currently
does. Three options are possible:
Chris tells me that an LLVM->GIMPLE translator wouldn't have target
dependencies. I'm not 100% sure I buy that, but I'll take it as given
for now (if not they shou
On Fri, Nov 18, 2005 at 05:50:52PM -0800, Chris Lattner wrote:
> * This will not support !
>
> As describe above, we won't support every target that GCC currently
> does. Three options are possible:
>
> 1. We (the GCC community) could build an LLVM to GIMPLE translator.
> This would probabl
23 matches
Mail list logo
