llvm dev - Jul 2007 - [LLVMdev] CallInst API Changes Ready [was: Re: llvm-gcc-4-2 development branch is open]

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>

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

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

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-2
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?

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

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