hello> > in the first step, we either have to backport the changes in the gcc > > frontend or port llvm-gcc to a more recent version (with the 4.2 > > release on its way, this might be a good candidate). it appears, > > resources are better spent for latter. are there major concerns > > speaking against this approach? does anybody have a rough estimate of > > the required effort? > > llvm-gcc is mostly affected by changes in the GCC trees. From my initial > investigation, it looks like there are a few minor changes (e.g. > CONSTRUCTOR nodes are a bit different) but nothing major. It may be > possible to get a prototype 4.2-merged compiler up in a few weeks. > > My group has plans to eventually merge the apple gcc 4.2 compiler work > into llvm-gcc. This would sync the front-end with 4.2 and provide several > other features contributed by apple (most of which may not be interesting > to people on non-darwin platforms though). Unfortunately, we don't have a > definite timespan for this. We'll most likely pick up this project in the > next 3-4 months. This may or may not be too late for you. >Because 3-4 months are a long time for us, i would like merge the llvm-gcc to a more recent version of gcc. Actually the fixed-point support for gcc is developed in a 4.3 branch which is regularly merged with the trunk. So there are 2 possible approaches: 1) port llvm-gcc to the actual fixed-point branch (gcc 4.3) 2) port llvm-gcc to gcc 4.2 and backport the fixed-point extensions to that llvm-gcc4.2 (i assume the backport will not be that much work because the frontends will not really differ) I think the decision basically depends on your release plans. If you want to keep track with the current 4.3 development, the first approach would be the better one. If you don't like a llvm-gcc release for every gcc release, the second approach seems better to me. So let me know about your preference. kind regards peter
On Feb 20, 2007, at 12:46 PM, Peter Wiedermann wrote:> > Because 3-4 months are a long time for us, i would like merge the > llvm-gcc to a more recent version of gcc. > > Actually the fixed-point support for gcc is developed in a 4.3 branch > which is regularly merged with the trunk. So there are 2 possible > approaches: > > 1) port llvm-gcc to the actual fixed-point branch (gcc 4.3) > > 2) port llvm-gcc to gcc 4.2 > and backport the fixed-point extensions to that llvm-gcc4.2 > (i assume the backport will not be that much work because the > frontends will not really differ) > > I think the decision basically depends on your release plans. > If you want to keep track with the current 4.3 development, the first > approach would be the better one. > If you don't like a llvm-gcc release for every gcc release, the second > approach seems better to me. > So let me know about your preference.LLVM may go the 4.2 route when it's done (formally released) and if the compile time regressions are fixed. 4.3 is still so far away, who knows when that's going to be done. I don't think it's likely the "official" llvm-gcc will go either 4.2 and 4.3 route in the immediate timeframe. It's possible for you to create your own 4.3 llvm-gcc branch. But you may be on your own for a while if you go that route. Evan> > kind regards > peter > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
On Tue, 20 Feb 2007, Peter Wiedermann wrote:> Actually the fixed-point support for gcc is developed in a 4.3 branch > which is regularly merged with the trunk. So there are 2 possible > approaches: > > 1) port llvm-gcc to the actual fixed-point branch (gcc 4.3)ok.> 2) port llvm-gcc to gcc 4.2 > and backport the fixed-point extensions to that llvm-gcc4.2 > (i assume the backport will not be that much work because the > frontends will not really differ)Right.> I think the decision basically depends on your release plans. If you > want to keep track with the current 4.3 development, the first approach > would be the better one. If you don't like a llvm-gcc release for every > gcc release, the second approach seems better to me. So let me know > about your preference.I'd strongly prefer you to take approach #2. GCC 4.2 itself isn't complete yet, and GCC 4.3 is likely to be significantly later than 4.2. I'd like for next version of llvm-gcc to be based on the released 4.2 (potentially with safe back-ported patches) rather than being based on the 4.3 development branch, which already has a large number of high-impact changes over what is in 4.2. -Chris -- http://nondot.org/sabre/ http://llvm.org/