Hi All, llvm-gcc-4-2 development branch is now open for development at llvm.org/svn/llvm-project/llvm-gcc-4-2 It is not yet ready, it can not even bootstrap. I welcome LLVM developers to test and apply fixes! However, first take a note of ground rules : 1) LLVM developers, use your write access as judiciously as you use it for LLVM development and follow same check-in procedure. 2) I'd appreciate if LLVM specific code is covered by appropriate markers. There are tons of existing examples in current sources. Entire LLVM support patch is covered by these markers. I might have removed code from llvm-gcc-4.0 that was required for LLVM support but was not covered under /* APPLE LOCAL <begin|end> LLVM */ markers. If someone feels strongly about word APPLE in these markers then feel free to change **ALL LLVM specific** markers to say /* LLVM LOCAL <begin|end> */. However, please do not change other markers that carry "APPLE LOCAL" string. 3) This svn module is for GCC-4.2 based front end for LLVM. Please do not check-in code from FSF GCC mainline (which uses 4.3 as version number). If you need a LLVM front end based on GCC 4.3, please create separate llvm.org/svn/llvm-project/llvm-gcc-4-3 module. 4) Keep llvm-gcc-4-2 GPLv3 free. Which means, do not back port code from other GCC development branches that has adopted GPLv3 lic. If FSF GCC 4.2 branch adopts GPLv3 then consult llvm oversight group first before back porting code from FSF GCC 4.2 branch. Thing that require immediate attention : 1) /* FIXME FIXME */ markers. :) 2) In GCC-4.2 CONSTRUCTOR_ELTS are now represented as VEC instead of a tree node chain. 3) FILE_TYPE, CHAR_TYPE etc.. tree nodes are gone. 4) In llvm-gcc x86 world, SSE intrinsics are listed in header file, where as FSF GCC lists them in source file. When I removed list from .c file, I did not synchronize it with .h file content. I'll let x86 code gen folks worry about it :) 5) There are many GCC tree structure changes that I have not noticed yet. Note, llvm-gcc-4-2 does not replace llvm-gcc-4-0. Current llvm-gcc FE (which is based on GCC-4.0) will be added in llvm svn at llvm.org/svn/ llvm-project/llvm-gcc-4-0. I have not picked up llvm-gcc-4-0 check-ins done in last few days in initial llvm-gcc-4-2 checkin. Enjoy! - Devang -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070711/fa792043/attachment.html>
David Greene
2007-Jul-11 23:55 UTC
[LLVMdev] CallInst API Changes Ready [was: Re: llvm-gcc-4-2 development branch is open]
On Wednesday 11 July 2007 17:03, Devang Patel wrote:> Hi All, > > llvm-gcc-4-2 development branch is now open for development at > > llvm.org/svn/llvm-project/llvm-gcc-4-2 > > It is not yet ready, it can not even bootstrap. I welcome LLVM > developers to test and apply fixes!How does this relate to the current llvm-gcc? Is that version still going to be added to the llvm svn repository? I ask because I'm ready to commit the CallInst interface changes and it will break llvm-gcc. There is no way to preserve the interfaces llvm-gcc needs because there are three places in the llvm-gcc code where the old interface conflicts with the new one (passing two Value*'s vs. passing two iterators to a template function). Again: when I commit the CallInst changes it will break llvm-gcc, and there's no way to avoid that. I can send an llvm-gcc patch for someone to apply, or if the current llvm-gcc is going to be put under subversion soon I can wait for that and commit the changes myself. Either way, we will want the CallInst and llvm-gcc changes to happen as close together in time as possible to minimize the chance of disrupting someone's work. -Dave
Devang Patel
2007-Jul-12 00:20 UTC
[LLVMdev] CallInst API Changes Ready [was: Re: llvm-gcc-4-2 development branch is open]
On Jul 11, 2007, at 4:55 PM, David Greene wrote:> On Wednesday 11 July 2007 17:03, Devang Patel wrote: >> Hi All, >> >> llvm-gcc-4-2 development branch is now open for development at >> >> llvm.org/svn/llvm-project/llvm-gcc-4-2 >> >> It is not yet ready, it can not even bootstrap. I welcome LLVM >> developers to test and apply fixes! > > How does this relate to the current llvm-gcc? Is that version still > going to > be added to the llvm svn repository?>> On Jul 11, 2007, at 3:03 PM, Devang Patel wrote: >> >> Note, llvm-gcc-4-2 does not replace llvm-gcc-4-0. Current llvm-gcc >> FE (which is based on GCC-4.0) will be added in llvm svn at >> llvm.org/svn/llvm-project/llvm-gcc-4-0. I have not picked up llvm- >> gcc-4-0 check-ins done in last few days in initial llvm-gcc-4-2 >> checkin- Devang
Reid Spencer
2007-Jul-12 00:25 UTC
[LLVMdev] CallInst API Changes Ready [was: Re: llvm-gcc-4-2 development branch is open]
David, llvm-gcc (4.0) will make it into the repository at llvm.org. It just hasn't yet. Devang's 4.2 compiler is not ready but was brought out into the light a bit to (hopefully) garner some help with it. We will soon have 3 C/C++ front ends in the repository :) Reid. On Wed, 2007-07-11 at 18:55 -0500, David Greene wrote:> On Wednesday 11 July 2007 17:03, Devang Patel wrote: > > Hi All, > > > > llvm-gcc-4-2 development branch is now open for development at > > > > llvm.org/svn/llvm-project/llvm-gcc-4-2 > > > > It is not yet ready, it can not even bootstrap. I welcome LLVM > > developers to test and apply fixes! > > How does this relate to the current llvm-gcc? Is that version still going to > be added to the llvm svn repository? > > I ask because I'm ready to commit the CallInst interface changes and it > will break llvm-gcc. There is no way to preserve the interfaces llvm-gcc > needs because there are three places in the llvm-gcc code where > the old interface conflicts with the new one (passing two Value*'s vs. > passing two iterators to a template function). > > Again: when I commit the CallInst changes it will break llvm-gcc, and > there's no way to avoid that. > > I can send an llvm-gcc patch for someone to apply, or if the current llvm-gcc > is going to be put under subversion soon I can wait for that and commit > the changes myself. Either way, we will want the CallInst and llvm-gcc > changes to happen as close together in time as possible to minimize the > chance of disrupting someone's work. > > -Dave > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Hi Devang, thanks very much for doing this.> 2) I'd appreciate if LLVM specific code is covered by appropriate > markers. There are tons of existing examples in current sources. > Entire LLVM support patch is covered by these markers. I might have > removed code from llvm-gcc-4.0 that was required for LLVM support but > was not covered under /* APPLE LOCAL <begin|end> LLVM */ markers. If > someone feels strongly about word APPLE in these markers then feel > free to change **ALL LLVM specific** markers to say /* LLVM LOCAL > <begin|end> */. However, please do not change other markers that > carry "APPLE LOCAL" string.I am in favour of changing markers to "/* LLVM LOCAL <begin|end> */". Shall I just do it?> 3) This svn module is for GCC-4.2 based front end for LLVM. Please do > not check-in code from FSF GCC mainline (which uses 4.3 as version > number). If you need a LLVM front end based on GCC 4.3, please create > separate llvm.org/svn/llvm-project/llvm-gcc-4-3 module.Is back-porting fixes from 4.3 OK?> 5) There are many GCC tree structure changes that I have not noticed > yet.I think STRING_CONSTANT is actually a constant in 4.2, which means all those tests for "is it a constant or a STRING_CONSTANT" in llvm-convert can be simplified.> Note, llvm-gcc-4-2 does not replace llvm-gcc-4-0. Current llvm-gcc FE > (which is based on GCC-4.0) will be added in llvm svn at llvm.org/svn/ > llvm-project/llvm-gcc-4-0. I have not picked up llvm-gcc-4-0 check-ins > done in last few days in initial llvm-gcc-4-2 checkin.What to do about new patches to 4.0? Should we insist that they also be applied to 4.2, if it makes sense to do so? Ciao, Duncan.
On Thu, 12 Jul 2007, Duncan Sands wrote:> I am in favour of changing markers to "/* LLVM LOCAL <begin|end> */". > Shall I just do it?Sure, go for it.>> 3) This svn module is for GCC-4.2 based front end for LLVM. Please do >> not check-in code from FSF GCC mainline (which uses 4.3 as version >> number). If you need a LLVM front end based on GCC 4.3, please create >> separate llvm.org/svn/llvm-project/llvm-gcc-4-3 module. > > Is back-porting fixes from 4.3 OK?It depends: today, yes, that's fine. Tomorrow (or, really soon now) no, that's not ok. We have a strong desire to keep llvm-gcc free of gpl v3 for the time being. As such, when GCC goes GPL v3 (which I hear is any day now), we won't be able to backport fixes from it. :( Luckily, GCC 4.2 was very recently released, so it's pretty fresh for the time being. Going forward, there is a low, but non-zero, chance that this might change. Alternatively, interested parties could start their own llvm-gcc-4.3 tree if they'd like.>> 5) There are many GCC tree structure changes that I have not noticed >> yet. > > I think STRING_CONSTANT is actually a constant in 4.2, which means all > those tests for "is it a constant or a STRING_CONSTANT" in llvm-convert > can be simplified.Nice!>> Note, llvm-gcc-4-2 does not replace llvm-gcc-4-0. Current llvm-gcc FE >> (which is based on GCC-4.0) will be added in llvm svn at llvm.org/svn/ >> llvm-project/llvm-gcc-4-0. I have not picked up llvm-gcc-4-0 check-ins >> done in last few days in initial llvm-gcc-4-2 checkin. > > What to do about new patches to 4.0? Should we insist that they also be > applied to 4.2, if it makes sense to do so?Sure, I think that makes sense. Right now, 4.2 is pretty broken. When it can build and bootstrap itself, I think that policy makes sense. -Chris -- http://nondot.org/sabre/ http://llvm.org/
On Jul 11, 2007, at 7:54 PM, Duncan Sands wrote:> Hi Devang, thanks very much for doing this. > >> 2) I'd appreciate if LLVM specific code is covered by appropriate >> markers. There are tons of existing examples in current sources. >> Entire LLVM support patch is covered by these markers. I might have >> removed code from llvm-gcc-4.0 that was required for LLVM support but >> was not covered under /* APPLE LOCAL <begin|end> LLVM */ markers. If >> someone feels strongly about word APPLE in these markers then feel >> free to change **ALL LLVM specific** markers to say /* LLVM LOCAL >> <begin|end> */. However, please do not change other markers that >> carry "APPLE LOCAL" string. > > I am in favour of changing markers to "/* LLVM LOCAL <begin|end> */". > Shall I just do it?Sure. If possible, do it in one check-in. Chris has already answered other questions. - Devang>> 3) This svn module is for GCC-4.2 based front end for LLVM. Please do >> not check-in code from FSF GCC mainline (which uses 4.3 as version >> number). If you need a LLVM front end based on GCC 4.3, please create >> separate llvm.org/svn/llvm-project/llvm-gcc-4-3 module. > > Is back-porting fixes from 4.3 OK? > >> 5) There are many GCC tree structure changes that I have not noticed >> yet. > > I think STRING_CONSTANT is actually a constant in 4.2, which means all > those tests for "is it a constant or a STRING_CONSTANT" in llvm- > convert > can be simplified. > >> Note, llvm-gcc-4-2 does not replace llvm-gcc-4-0. Current llvm-gcc FE >> (which is based on GCC-4.0) will be added in llvm svn at llvm.org/ >> svn/ >> llvm-project/llvm-gcc-4-0. I have not picked up llvm-gcc-4-0 check- >> ins >> done in last few days in initial llvm-gcc-4-2 checkin. > > What to do about new patches to 4.0? Should we insist that they > also be > applied to 4.2, if it makes sense to do so? > > Ciao, > > Duncan.
> 2) I'd appreciate if LLVM specific code is covered by appropriate > markers. There are tons of existing examples in current sources. > Entire LLVM support patch is covered by these markers. I might have > removed code from llvm-gcc-4.0 that was required for LLVM support but > was not covered under /* APPLE LOCAL <begin|end> LLVM */ markers. If > someone feels strongly about word APPLE in these markers then feel > free to change **ALL LLVM specific** markers to say /* LLVM LOCAL > <begin|end> */. However, please do not change other markers that > carry "APPLE LOCAL" string.Do you want in-tree changelogs for LLVM changes that touch general gcc files (i.e. outside the llvm* files), like Apple maintains in ChangeLog.apple? Hopefully not! Thanks, Duncan.
Hi Devang,> llvm-gcc-4-2 development branch is now open for development at > > llvm.org/svn/llvm-project/llvm-gcc-4-2I noticed the following difference between llvm-gcc and llvm-gcc-4-2 in gcc/llvm-linker-hack.cpp, any idea where it came from? Thanks, Duncan. @@ -28,6 +28,7 @@ #include "llvm/Bitcode/ReaderWriter.h" #include "llvm/CodeGen/ScheduleDAG.h" #include "llvm/CodeGen/Passes.h" +#include "llvm/Support/MemoryBuffer.h" #include "llvm/Support/Streams.h" /// dummy_function - This is used when linking the LLVM libraries into a dynamic @@ -40,8 +41,10 @@ void dummy_function() { new llvm::ExistingModuleProvider(0); llvm::createVerifierPass(); - llvm::WriteBitcodeToFile(0, llvm::cout); + llvm::CreateBitcodeWriterPass(*llvm::cout); + llvm::WriteBitcodeToFile(0, *llvm::cout); llvm::ParseBitcodeFile(NULL); + llvm::MemoryBuffer::getNewMemBuffer(0); llvm::createInstructionCombiningPass(); llvm::createScalarReplAggregatesPass();
On Fri, 13 Jul 2007, Duncan Sands wrote:> Do you want in-tree changelogs for LLVM changes that touch general gcc > files (i.e. outside the llvm* files), like Apple maintains in ChangeLog.apple? > Hopefully not!I have never understood the use of GCC-style changelogs. Regardless, we never kept them for llvm-gcc 4.0, so I don't think we need them for 4.2. Do you agree Devang? -Chris -- http://nondot.org/sabre/ http://llvm.org/
On Fri, 13 Jul 2007, Duncan Sands wrote:> I noticed the following difference between llvm-gcc and llvm-gcc-4-2 > in gcc/llvm-linker-hack.cpp, any idea where it came from?This is probably a patch that got checked into llvm-gcc4 after devang started work on 4.2. Please feel free to update 4.2 to the version in 4.0. Thanks! -Chris> @@ -28,6 +28,7 @@ > #include "llvm/Bitcode/ReaderWriter.h" > #include "llvm/CodeGen/ScheduleDAG.h" > #include "llvm/CodeGen/Passes.h" > +#include "llvm/Support/MemoryBuffer.h" > #include "llvm/Support/Streams.h" > > /// dummy_function - This is used when linking the LLVM libraries into a dynamic > @@ -40,8 +41,10 @@ > void dummy_function() { > new llvm::ExistingModuleProvider(0); > llvm::createVerifierPass(); > - llvm::WriteBitcodeToFile(0, llvm::cout); > + llvm::CreateBitcodeWriterPass(*llvm::cout); > + llvm::WriteBitcodeToFile(0, *llvm::cout); > llvm::ParseBitcodeFile(NULL); > + llvm::MemoryBuffer::getNewMemBuffer(0); > > llvm::createInstructionCombiningPass(); > llvm::createScalarReplAggregatesPass(); > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-Chris -- http://nondot.org/sabre/ http://llvm.org/
On Jul 13, 2007, at 3:29 AM, Duncan Sands wrote:>> 2) I'd appreciate if LLVM specific code is covered by appropriate >> markers. There are tons of existing examples in current sources. >> Entire LLVM support patch is covered by these markers. I might have >> removed code from llvm-gcc-4.0 that was required for LLVM support but >> was not covered under /* APPLE LOCAL <begin|end> LLVM */ markers. If >> someone feels strongly about word APPLE in these markers then feel >> free to change **ALL LLVM specific** markers to say /* LLVM LOCAL >> <begin|end> */. However, please do not change other markers that >> carry "APPLE LOCAL" string. > > Do you want in-tree changelogs for LLVM changes that touch general gcc > files (i.e. outside the llvm* files), like Apple maintains in > ChangeLog.apple? > Hopefully not!I am not worried about ChangeLogs. - Devang
David Greene
2007-Jul-16 16:57 UTC
[LLVMdev] CallInst API Changes Ready [was: Re: llvm-gcc-4-2 development branch is open]
On Wednesday 11 July 2007 18:55, David Greene wrote:> I ask because I'm ready to commit the CallInst interface changes and it > will break llvm-gcc. There is no way to preserve the interfaces llvm-gcc > needs because there are three places in the llvm-gcc code where > the old interface conflicts with the new one (passing two Value*'s vs. > passing two iterators to a template function). > > Again: when I commit the CallInst changes it will break llvm-gcc, and > there's no way to avoid that. > > I can send an llvm-gcc patch for someone to apply, or if the current > llvm-gcc is going to be put under subversion soon I can wait for that and > commit the changes myself. Either way, we will want the CallInst and > llvm-gcc changes to happen as close together in time as possible to > minimize the chance of disrupting someone's work.Haven't heard anything back on this. I'd like to get these changes in before they become bitrotted. -Dave