Hello, I've been looking at LDC sources and it seems a bit weird to me, that DMD is not used as a submodule. If LDC aims to provide LLVM generation, using original DMD as a frontend, it will get hard to maintain merges from original DMD over time. And it seems to me, that it is already, as DMD is not up-to-date there. E.g. while DMD factored out toIR and toElem to visitors, LDC still uses old design.

If i'm right and such problem exists, what do you think of the following plan to fix this:
1. Create a DMD fork. Create an ldc-dmd branch in it, and replace it's contents with current DMD state in LDC.
2. Start using DMD fork with it's ldc-branch in LDC repo as a submodule.
3. Gradually refactor LDC and ldc-dmd branch with the goal to completely eliminate differences between ldc-dmd branch and DMD fork master.
4. Repeat step 3, until complete =)
5. Switch submodule to DMD fork master, and close dmd-ldc branch.

Hi Yuriy!

On Monday, 24 March 2014 at 09:51:34 UTC, Yuriy wrote:
> Hello, I've been looking at LDC sources and it seems a bit weird to me, that DMD is not used as a submodule. If LDC aims to provide LLVM generation, using original DMD as a frontend, it will get hard to maintain merges from original DMD over time. And it seems to me, that it is already, as DMD is not up-to-date there. E.g. while DMD factored out toIR and toElem to visitors, LDC still uses old design.
>
> If i'm right and such problem exists, what do you think of the following plan to fix this:
> 1. Create a DMD fork. Create an ldc-dmd branch in it, and replace it's contents with current DMD state in LDC.
> 2. Start using DMD fork with it's ldc-branch in LDC repo as a submodule.
> 3. Gradually refactor LDC and ldc-dmd branch with the goal to completely eliminate differences between ldc-dmd branch and DMD fork master.
> 4. Repeat step 3, until complete =)
> 5. Switch submodule to DMD fork master, and close dmd-ldc branch.

Well, merging the DMD frontend is not the problem. The merge-2.064 and merge-2.065 contains the merge of the last 2 DMD releases. (The latter one contains the refactoring using visitor pattern.)
In fact, I have a MSBUILD script to do the merge - I only have to resolve conflicts, which is usually simple.

The real problem is that a change in the frontend must be handled in the glue layer between frontend AST and LLVM IR. This must always be done manually.

E.g.: there is only 1 test failure left in the merge-2.064 branch: a missing symbol in std.uni unittest. The merge-2.065 branch has some more problems in phobos unit tests - because I did not fixed the changes.

Any help here is appreciated.

Regards,
Kai

I wonder what the planned move to D for the frontend will mean for ldc/gdc's future.

On 24/04/14 21:27, Trass3r via digitalmars-d-ldc wrote:
> I wonder what the planned move to D for the frontend will mean for
> ldc/gdc's future.

The shift towards the visitor interface for accessing the AST was primarily motivated by the need to be able to keep the codegen layer in C++ even if the frontend is switched to D. We extensively discussed this at the last DConf, and the impact of the switch on both GDC and LDC will be reasonably small.

Best,
David

Good to hear :)

> E.g.: there is only 1 test failure left in the merge-2.064 branch: a missing symbol in std.uni unittest. The merge-2.065 branch has some more problems in phobos unit tests - because I did not fixed the changes.

Tested the x64 MSVC combination and the 2.065 branch crashes when building the runtime. 2.064 has less problems but now I enabled llvm assertions and it hits 2 of them. Do you build with assertions?

Hi Trass3r!

On Sunday, 27 April 2014 at 16:25:05 UTC, Trass3r wrote:
>> E.g.: there is only 1 test failure left in the merge-2.064 branch: a missing symbol in std.uni unittest. The merge-2.065 branch has some more problems in phobos unit tests - because I did not fixed the changes.
>
> Tested the x64 MSVC combination and the 2.065 branch crashes when building the runtime. 2.064 has less problems but now I enabled llvm assertions and it hits 2 of them. Do you build with assertions?

Yes, I build with assertions enabled. Which assertions do you hit? And which LLVM version do you use?

Regards,
Kai

> Yes, I build with assertions enabled. Which assertions do you hit? And which LLVM version do you use?

Trunk llvm, VS2013.
Need to look up the messages tomorrow.

On Tuesday, 29 April 2014 at 18:26:44 UTC, Trass3r wrote:
>> Yes, I build with assertions enabled. Which assertions do you hit? And which LLVM version do you use?
>
> Trunk llvm, VS2013.
> Need to look up the messages tomorrow.

Ok 2.064 branch, latest llvm.

3>------ Build started: Project: druntime-ldc, Configuration: RelWithDebInfo x64 ------
4>------ Build started: Project: druntime-ldc-debug, Configuration: RelWithDebInfo x64 ------
4>  Generating src/core/atomic-debug.obj
3>  Generating src/core/atomic.obj
4>  Assertion failed: List && "Handle list is null?", file ..\..\..\lib\IR\Value.cpp, line 528
3>  Assertion failed: List && "Handle list is null?", file ..\..\..\lib\IR\Value.cpp, line 528
5>------ Build started: Project: phobos-ldc, Configuration: RelWithDebInfo x64 ------
5>  Generating std/algorithm.obj
6>------ Build started: Project: phobos-ldc-debug, Configuration: RelWithDebInfo x64 ------
6>  Generating std/algorithm-debug.obj
5>  Assertion failed: (!F || F->getParent() == &M) && "Function not in current module!", file ..\..\..\..\lib\Analysis\IPA\CallGraph.cpp, line 149
6>  Assertion failed: (!F || F->getParent() == &M) && "Function not in current module!", file ..\..\..\..\lib\Analysis\IPA\CallGraph.cpp, line 149

On Wednesday, 30 April 2014 at 10:10:39 UTC, Trass3r wrote:
> On Tuesday, 29 April 2014 at 18:26:44 UTC, Trass3r wrote:
>>> Yes, I build with assertions enabled. Which assertions do you hit? And which LLVM version do you use?
>>
>> Trunk llvm, VS2013.
>> Need to look up the messages tomorrow.
>
> Ok 2.064 branch, latest llvm.
>
> 3>------ Build started: Project: druntime-ldc, Configuration: RelWithDebInfo x64 ------
> 4>------ Build started: Project: druntime-ldc-debug, Configuration: RelWithDebInfo x64 ------
> 4>  Generating src/core/atomic-debug.obj
> 3>  Generating src/core/atomic.obj
> 4>  Assertion failed: List && "Handle list is null?", file ..\..\..\lib\IR\Value.cpp, line 528
> 3>  Assertion failed: List && "Handle list is null?", file ..\..\..\lib\IR\Value.cpp, line 528
> 5>------ Build started: Project: phobos-ldc, Configuration: RelWithDebInfo x64 ------
> 5>  Generating std/algorithm.obj
> 6>------ Build started: Project: phobos-ldc-debug, Configuration: RelWithDebInfo x64 ------
> 6>  Generating std/algorithm-debug.obj
> 5>  Assertion failed: (!F || F->getParent() == &M) && "Function not in current module!", file ..\..\..\..\lib\Analysis\IPA\CallGraph.cpp, line 149
> 6>  Assertion failed: (!F || F->getParent() == &M) && "Function not in current module!", file ..\..\..\..\lib\Analysis\IPA\CallGraph.cpp, line 149

I do not get assertions errors. I use VS2012. But my LLVM tree is more than a week old. I currently build LLVM. Maybe it is something new...

Regards,
Kai