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. :slight_smile:

  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 :slight_smile:

  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!

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

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 :slight_smile:

Reid.

Heh. Missed that. :slight_smile:

Do we have a timeframe on this? I want to get these CallInst changes in so
that --enable-expensive-checks is useful for others.

This also means that changes to llvm-gcc will have to be pushed into both
places. Ugh. I don't know of a better way to do it, though. Branching seems
overly complex.

                                          -Dave

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.

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. :frowning:

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

Sure. If possible, do it in one check-in.

Chris has already answered other questions.

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();

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

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@cs.uiuc.edu http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-Chris

Hi Chris,

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.

no, it doesn't exist in 4.0. I already updated 4.2 to 4.0 by the way.

Ciao,

Duncan.

I am not worried about ChangeLogs.

hmm. that can not be true. It was applied by Evan on May 07, 2007 to unbreak Apple style builds.

Hi Chris,

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

I agree ChangeLogs are redundant given modern RCSes. There is one
related bit of GPL V2 that says

    a) You must cause the modified files to carry prominent notices
    stating that you changed the files and the date of any change.

so, being a license pedant, if any of the source falls under GPL V2 and
you're modifying and distributing it, you should make some attempt to
meet 2(a).

IANAL, etc. :slight_smile:

Cheers,

Ralph.

Hi Devang,

>> 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.
>
> no, it doesn't exist in 4.0.

hmm. that can not be true. It was applied by Evan on May 07, 2007 to
unbreak Apple style builds.

this difference exists between llvm-gcc-4.0 (the mirror) and llvm-gcc-4.2
today, check llvm-linker-hack.cpp yourself if you like. There was a change
to the mirror in May 07, but it was just changing Bytecode -> Bitcode. My
guess is the Evan's change didn't reach the mirror. Here is the function
as it exists in the llvm-gcc-4.0 mirror today:

void dummy_function() {
  new llvm::ExistingModuleProvider(0);
  llvm::createVerifierPass();
  llvm::WriteBitcodeToFile(0, llvm::cout);
  llvm::ParseBitcodeFile(NULL);
...

and in llvm-gcc-4.2:
void dummy_function() {
  new llvm::ExistingModuleProvider(0);
  llvm::createVerifierPass();
  llvm::CreateBitcodeWriterPass(*llvm::cout);
  llvm::WriteBitcodeToFile(0, *llvm::cout);
  llvm::ParseBitcodeFile(NULL);
  llvm::MemoryBuffer::getNewMemBuffer(0);

If the llvm-gcc-4.2 version is correct, the mirror needs to be corrected.
Not sure how to do that...

Ciao,

Duncan.

I believe we satisfy that requirement by updating the copyright block (e.g.):

    Copyright (C) 1987, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
    1999, 2000, 2001, 2002, 2003, 2004, 2005, 2007 Free Software
    Foundation, Inc.

and by marking our changes with LLVM LOCAL.

-Chris

I checked out llvm-gcc-4.0 from mirror svn server and our internal svn.
And I do see the difference, but I do not understand why.

Bill, any idea ?

Haven't heard anything back on this. I'd like to get these changes in
before they become bitrotted.

                                               -Dave