Create branch for llvm 3.2

[redstar]

Since llvm 3.1 is released now I propose to change the repository layout:

• branch master into branch llvm-3.0 for maintenance
• merge llvm-3.1 branch into master branch and delete it
• create new branch llvm-3.2

Any objections?

[dnadlinger]

Seems like a reasonable thing to do. Dejan from #[email protected] mentioned that he would maybe be willing to maintain the llvm-3.0 branch.

[dnadlinger]

I originally thought that it might be a good idea to keep master based on 3.0 until the next release, as there are no big 3.1-specific improvements in LDC yet (except for Windows, I suppose), to avoid forcing people on Linux to compile LLVM from source, as 3.1 packages are not widely available yet.

However, it looks like we are not going to be able to push a release in the next few weeks: at least I won't have much time to prepare it, and it would really make sense to wait for DMD 2.060 to get the recently landed x86_64 ABI fixes (otherwise, we would temporarily have to patch the frontend and druntime in order to fix #73, only to reconcile it with the upstream changes later).

In order to continue working on the ABI stuff, it would make sense to keep a public branch around with the latest Git DMD, but doing that with the current 3.0/3.1 split, and maybe an additional 3.2 branch as well, would probably lead to a confusing mess. Thus, I'd agree that we should make llvm-3.1 the master branch – when the release is made, the changes could always be backported to 3.0 as well, if it is then still deemed necessary.

[dnadlinger]

Hm, on the other hand, if we end up at least partially supporting LLVM 3.0, we'd have to do an unholy mess of cherry-picking. Really depends on whether we will depend on some 3.1-only features (Windows Dwarf EH?) in the next release – I guess not.

What would also be worth looking into is handling minor LLVM releases via conditional compilation in a single branch, if the API stays as stable in the future as it did for 3.0 -> 3.1.

[dnadlinger]

I just had another short look at the situation, and I think the most sensible approach for the time being would be to just merge the two branches, and in the few places where LLVM 3.0 and 3.1 are not source compatible, use conditional compilation (this unfortunately also includes an intrinsic). LLVM 3.1 would be the main tested and supported target, with 3.0 intended to be working as well, but a note of caution attached (I imagine that we would occasionally break the 3.0 build).

Sure, this adds a bit of extra complication, but I think it might be still much less of a hassle than continuously maintaining two branches, which is what we are doing right now. Once the API differences become too big to reasonably handle (I'm not quite up to date with what's planned for 3.2), we could just drop support for older versions (in the form of removing #ifdefs, …).

To me, this seems to be a good balance between maintenance effort and ease of use for people who want to eschew building LLVM from source.

[redstar]

Closing this issue because master will support all versions of LLVM.

[redstar]

Branch master now compiles with all LLVM 3.x versions. I merged llvm-3.1 into master and ldc-llvm-3.1 into ldc. Should we delete the llvm-3.1 branches now?

[dnadlinger]

Hm, your last commit somehow broke fast-forward merges for all my clones, so I (urgh) had to force-reset the GitHub repo to 76cf66f. This should be enough anyway – or do we need to merge the branch into master? If there is no good reason, I'd even prefer to go this way for a cleaner history.

As far as the llvm-3.1 branch is concerned, I don't want to just delete it outright, as several distro builds are using it. I'll push a change which makes CMake fail with an explanatory error message – we can just delete it afterwards.

[redstar]

Sorry for that. I performed the merge only to have a clean state to delete the branch. I admit that the behaviour of git was a bit confusing in this case. The force-reset is no problem.

[dnadlinger]

What I don't quite understand is why none of my local repositories would cleanly fast-forward to your commit, as it looked like a normal merge commit. Anyway, I hope that if anybody tried to pull from upstream in that two hours, they got the same error and couldn't merge – rewriting history in public repositories is a problem (at least if that someone wants to contribute back at some point).