On Tue, Dec 16, 2008 at 9:43 PM, Don <nospam@nospam.com> wrote:
> Bill Baxter wrote:
>>
>> Anyway, all that said,  it's not clear that we really do have that mythical "uber backend" available right now.
>>
>> According to my conversations on the clang mailing list, the current
>> target is for LLVM to be able to fully support a C++ compiler by 2010.
>>  I'm not quite sure what all that involves, but apparently it includes
>> things like making exceptions work on Windows.
>
> I wonder if there's any chance of getting a LLVM D compiler working before the LLVM C++ compiler works? <g>

Sounds to me like LDC is already ahead of clang's C++.
I actually asked the same question over on the list "could it be that
LDC is already the most advanced compiler availble on the LLVM
platform?"  One guy answered "No, there's llvm-g++", but another guy
answered "it depends on whether you count llvm-g++ as an LLVM-based
compiler or not".    I'm not sure what llvm-g++ is, but from that I'm
guessing maybe it's an llvm front end with a g++ back-end.  In which
case, I wouldn't really count it.

But there are a lot of LLVM projects listed here:
http://llvm.org/ProjectsWithLLVM/
Maybe one of those is more advanced than LDC, not that "advanced" has
a very specific meaning anyway.

LDC should definitely be on that list, though.

--bb

> Sounds to me like LDC is already ahead of clang's C++.
> I actually asked the same question over on the list "could it be that
> LDC is already the most advanced compiler availble on the LLVM
> platform?"  One guy answered "No, there's llvm-g++", but another guy
> answered "it depends on whether you count llvm-g++ as an LLVM-based
> compiler or not".    I'm not sure what llvm-g++ is, but from that I'm
> guessing maybe it's an llvm front end with a g++ back-end.  In which
> case, I wouldn't really count it.
> 
> But there are a lot of LLVM projects listed here:
> http://llvm.org/ProjectsWithLLVM/
> Maybe one of those is more advanced than LDC, not that "advanced" has
> a very specific meaning anyway.
> 
> LDC should definitely be on that list, though.
> 
> --bb

llvm-gcc and -g++ are the gcc/g++ front ends bolted onto the llvm middle/backends.  So in that respect, almost identical to dmd's fe bolted onto llvm.  The major difference being that llvm-gcc/g++ are complete (as far as gcc and llvm are complete)

There used to be a C backend to llvm, but that was abandoned a year or two ago, if I recall correctly.  As far as I know, there's never been a c++ backend, nor any use of gcc's backends with llvm.

Since LDC isn't re-implementing the frontend of d, just splicing dmd's onto llvm and that clang is still implementing both c and c++, yes, ldc is further along in some ways than clang is.  But it's not exactly an apples to apples comparison (please pardon the pun).

Later,
Brad

On Wed, Dec 17, 2008 at 12:36 PM, Brad Roberts <braddr@puremagic.com> wrote:
>> Sounds to me like LDC is already ahead of clang's C++.
>> I actually asked the same question over on the list "could it be that
>> LDC is already the most advanced compiler availble on the LLVM
>> platform?"  One guy answered "No, there's llvm-g++", but another guy
>> answered "it depends on whether you count llvm-g++ as an LLVM-based
>> compiler or not".    I'm not sure what llvm-g++ is, but from that I'm
>> guessing maybe it's an llvm front end with a g++ back-end.  In which
>> case, I wouldn't really count it.
>>
>> But there are a lot of LLVM projects listed here:
>> http://llvm.org/ProjectsWithLLVM/
>> Maybe one of those is more advanced than LDC, not that "advanced" has
>> a very specific meaning anyway.
>>
>> LDC should definitely be on that list, though.
>>
>> --bb
>
> llvm-gcc and -g++ are the gcc/g++ front ends bolted onto the llvm middle/backends.  So in that respect, almost identical to dmd's fe bolted onto llvm.  The major difference being that llvm-gcc/g++ are complete (as far as gcc and llvm are complete)

Ah, ok.  Thanks for clearing that up.  So that means I probably should
have been bugging the llvm-g++ guys instead of the clang guys.
So what is llvm-g++ doing about exception handling and Windows support?
Guess I'll have to go sign up for another mailing list now to find out...

> Since LDC isn't re-implementing the frontend of d, just splicing dmd's onto llvm and that clang is still implementing both c and c++, yes, ldc is further along in some ways than clang is.  But it's not exactly an apples to apples comparison (please pardon the pun).

Got it.

--bb

Christian Kamm:
>>>> No, unfortunately.
>>>> It's a problem with LLVM only supporting Dwarf2 exception handling. I'm
>>>> pretty sure it'd work if we used ELF for the object files and GCC for
>>>> linking, but Windows people tell me this is hardly acceptable.

dsimcha:
>>> I think this solution is much better than nothing.  I assume it would
>>> at least
>>> work ok on standalone-type projects.

Aarti_pl:
>> Yeah... Also my thoughts...
>> 
>> Additionally maybe there are 3rd party object files converters, and "Windows people" work could be done using them as workaround?

Aarti_pl:
> I found such a converter (GPL licenced):
> http://agner.org/optimize/#objconv
> 
> Can anyone comment if such a workaround will solve initial problem? (at
> least temporary).

I doubt it. This utility strips incompatible debug and exception handling information by default and I don't know what happens if you tell it not to. It's pretty likely the runtime won't find the tables in the foreign object format.

Also, you'd still need GCC's dwarf2 unwinding runtime.

Christian Kamm pisze:
> Christian Kamm:
>>>>> No, unfortunately.
>>>>> It's a problem with LLVM only supporting Dwarf2 exception handling. I'm
>>>>> pretty sure it'd work if we used ELF for the object files and GCC for
>>>>> linking, but Windows people tell me this is hardly acceptable.
> 
> dsimcha:
>>>> I think this solution is much better than nothing.  I assume it would
>>>> at least
>>>> work ok on standalone-type projects.
> 
> Aarti_pl:
>>> Yeah... Also my thoughts...
>>>
>>> Additionally maybe there are 3rd party object files converters, and
>>> "Windows people" work could be done using them as workaround?
> 
> Aarti_pl:
>> I found such a converter (GPL licenced):
>> http://agner.org/optimize/#objconv
>>
>> Can anyone comment if such a workaround will solve initial problem? (at
>> least temporary).
> 
> I doubt it. This utility strips incompatible debug and exception handling
> information by default and I don't know what happens if you tell it not to.
> It's pretty likely the runtime won't find the tables in the foreign object
> format.
> 
> Also, you'd still need GCC's dwarf2 unwinding runtime.

Well, I am not very familiar with internals of compilers.

I just would like to put my hands on fully working LDC on windows :-)

Just one more thought: Agner Fog seems to live in Copenhagen. Maybe it would be good idea to contact with him? Especially for Thomas :-)

Anyway, thanks for your great work.

BR
Marcin Kuszczak
(aarti_pl)

aarti_pl wrote:
> Christian Kamm pisze:
>> Christian Kamm:
>>>>>> No, unfortunately.
>>>>>> It's a problem with LLVM only supporting Dwarf2 exception handling. I'm
>>>>>> pretty sure it'd work if we used ELF for the object files and GCC for
>>>>>> linking, but Windows people tell me this is hardly acceptable.
>>
>> dsimcha:
>>>>> I think this solution is much better than nothing.  I assume it would
>>>>> at least
>>>>> work ok on standalone-type projects.
>>
>> Aarti_pl:
>>>> Yeah... Also my thoughts...
>>>>
>>>> Additionally maybe there are 3rd party object files converters, and
>>>> "Windows people" work could be done using them as workaround?
>>
>> Aarti_pl:
>>> I found such a converter (GPL licenced):
>>> http://agner.org/optimize/#objconv
>>>
>>> Can anyone comment if such a workaround will solve initial problem? (at
>>> least temporary).
>>
>> I doubt it. This utility strips incompatible debug and exception handling
>> information by default and I don't know what happens if you tell it not to.
>> It's pretty likely the runtime won't find the tables in the foreign object
>> format.
>>
>> Also, you'd still need GCC's dwarf2 unwinding runtime.
> 
> Well, I am not very familiar with internals of compilers.
> 
> I just would like to put my hands on fully working LDC on windows :-)
> 
> Just one more thought: Agner Fog seems to live in Copenhagen. Maybe it would be good idea to contact with him? Especially for Thomas :-)

I'm in contact with him (I contributed to the latest objconv). But don't expect too much -- objconv doesn't do much more than DDL.
Adding exception support to LLVM is probably *much* easier than converting the exception support in a compiled object file.

Don wrote:
> Adding exception support to LLVM is probably *much* easier than converting the exception support in a compiled object file.

There's no way to add it to a compiled object file. The schemes are completely different, and interact with the rest of the code generation. Might as well try to turn hamburger back into a cow.

Don wrote:
>> Adding exception support to LLVM is probably *much* easier than converting the exception support in a compiled object file.

Walter Bright wrote:
> There's no way to add it to a compiled object file. The schemes are completely different, and interact with the rest of the code generation. Might as well try to turn hamburger back into a cow.

Yes. The most sensible approach would be adding SEH support to LLVM. Neither Tomas nor me are planning to do it though. We hope that someone who actually develops on Windows will volunteer.

As clang and llvm-gcc would also benefit from it, this might do well as a Summer of Code project at LLVM. From what I hear exception support in LLVM is due for a revamp anyway, so anyone attempting to do this would probably get a chance to help redesign the infrastructure and be well supported by the LLVM devs.