IPA branch
Jan -- I'm trying to plan for GCC 4.3 Stage 1. The IPA branch project is clearly a good thing, and you've been working on it for a long time, so I'd really like to get it into GCC 4.3. However, I'm a little concerned, in reading the project description, that it's not all that far along. I'm hoping that I'm just not reading the description well, and that you can explain things in a way that makes it obvious to me that the work is actually almost done. The Wiki page says "first part of patches was already sent", but I can't tell how much that is, or how many of the "modifications required" steps are already done. Have you completed all the work on the IPA branch itself, so that it's just a problem of merging? How much of the merging have you actually done? What version of mainline corresponds to the root of the IPA branch? Have maintainers with appropriate write privileges reviewed the patches? I'm not in any way trying to send a negative signal about this work. I have every hope that it will be merged soon. I just want to better understand the situation. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
GCC 4.3 Merge Plan
[N.B. -- We are not in Stage 1 yet!] I've categorized the projects submitted for 4.3 into Stage 1 and Stage 2 projects. The criteria I've used are (a) completeness (projects that are more complete should go in earlier), (b) riskiness (projects that are riskier, affect more targets, etc., should go in earlier). I've also tried to give priority to projects that were submitted for 4.2, but didn't make it in. Feedback is welcome. As always, you still need to get your patches reviewed before check-in; the fact that your project is on the list doesn't imply that it will actually be accepted, though, of course, that is the hope. Here are some additional ground rules and notes: * Recruit a Reviewer If you can't approve your own contribution, please locate an appropriate reviewer now. Find a person or people who will commit to reviewing your patch, and put their name on your project Wiki page. Lining up a reviewer can be more important that finishing the code; in the past, we've had the problem of completed patches, but with no reviewer available. * Check-in Windows If you are contributing a project, and think you are almost ready to check in your code, please announce that fact. From the point of your announcement, you have a 72-hour window to get the contribution done. During your window,, you can impose your own check-in rules on mainline. In general, please let people to continue to check as many things in as possible -- but if you really need to lock everything down to test on multiple platforms, etc., you have the freedom to do that. Before you make your reservation, you should have merged, tested, and have had your patches reviewed. The reservation should just be for a final merge/test/check-in cycle. When you're done, please announce that the branch has reverted to normal rules. * Stage 2 Projects If you have a Stage 2 project that's ready, reviewed, and tested, you can check in early. For example, the Stage 2 list has architecture-specific work listed for ARM, ColdFire, and x86-64. If that work is ready, it's unlikely to affect the Stage 1 work, so it's fine for it to go in early. The reason it's in Stage 2 is that it wouldn't perturb me for it to go in during Stage 2; in contrast, the new dataflow stuff should go in soon so that we have time to fix any problems that arise and so that future work can build on that platform. However, if you are going to commit early, please announce that fact at least 72 hours before you actually do your check-in, so that people working on Stage 1 projects can ask you to wait, and please respect ay such requests. * Internal Ordering I'm not going to try to order the Stage 1 projects. When you're ready, go ahead and commit. But, please do try to keep other developers informed of your intentions. * Submit Early Remember that Stage 1 isn't really the time to be doing major development; it's primarily the time to be *merging* major development. So, get your branches merged up to mainline, write documentation, do tests, and submit your patches. There's no reason a patch for Stage 1 can't be completed and submitted in Stage 2/Stage 3 of the previous release cycle. You can certainly submit your Stage 2 patch during Stage 1. * Uncategorized Projects I've left the Fixed-Point Arithmetic and Variadic Templates projects as uncategorized for the moment. The fact that these projects aren't (yet) on the merge plan doesn't mean that they're not nice projects. However, the former looks like a very substantial change, and isn't done yet, so my tentative feeling is that it should wait for GCC 4.4, by which point it will hopefully be more complete. The latter requires consensus on C++ 0x. I plan to summarize what I think the consensus is for the development list, and then ask for SC ratification. I'd be happy to see both of these projects in GCC 4.3 if all the pieces come together in time. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
The Linux binutils 2.17.50.0.4 is released
This is the beta release of binutils 2.17.50.0.4 for Linux, which is
based on binutils 2006 0924 in CVS on sources.redhat.com plus various
changes. It is purely for Linux.
Starting from the 2.17.50.0.4 release, the default output section LMA
(load memory address) has changed for allocatable sections from being
equal to VMA (virtual memory address), to keeping the difference between
LMA and VMA the same as the previous output section in the same region.
For
.data.init_task : { *(.data.init_task) }
LMA of .data.init_task section is equal to its VMA with the old linker.
With the new linker, it depends on the previous output section. You
can use
.data.init_task : AT (ADDR(.data.init_task)) { *(.data.init_task) }
to ensure that LMA of .data.init_task section is always equal to its
VMA. The linker script in the older 2.6 x86-64 kernel depends on the
old behavior. You can add AT (ADDR(section)) to force LMA of
.data.init_task section equal to its VMA. It will work with both old
and new linkers. The x86-64 kernel linker script in kernel 2.6.13 and
above is OK.
The new x86_64 assembler no longer accepts
monitor %eax,%ecx,%edx
You should use
monitor %rax,%ecx,%edx
or
monitor
which works with both old and new x86_64 assemblers. They should
generate the same opcode.
The new i386/x86_64 assemblers no longer accept instructions for moving
between a segment register and a 32bit memory location, i.e.,
movl (%eax),%ds
movl %ds,(%eax)
To generate instructions for moving between a segment register and a
16bit memory location without the 16bit operand size prefix, 0x66,
mov (%eax),%ds
mov %ds,(%eax)
should be used. It will work with both new and old assemblers. The
assembler starting from 2.16.90.0.1 will also support
movw (%eax),%ds
movw %ds,(%eax)
without the 0x66 prefix. Patches for 2.4 and 2.6 Linux kernels are
available at
http://www.kernel.org/pub/linux/devel/binutils/linux-2.4-seg-4.patch
http://www.kernel.org/pub/linux/devel/binutils/linux-2.6-seg-5.patch
The ia64 assembler is now defaulted to tune for Itanium 2 processors.
To build a kernel for Itanium 1 processors, you will need to add
ifeq ($(CONFIG_ITANIUM),y)
CFLAGS += -Wa,-mtune=itanium1
AFLAGS += -Wa,-mtune=itanium1
endif
to arch/ia64/Makefile in your kernel source tree.
Please report any bugs related to binutils 2.17.50.0.4 to [EMAIL PROTECTED]
and
http://www.sourceware.org/bugzilla/
If you don't use
# rpmbuild -ta binutils-xx.xx.xx.xx.xx.tar.bz2
to compile the Linux binutils, please read patches/README in source
tree to apply Linux patches if there are any.
Changes from binutils 2.17.50.0.3:
1. Update from binutils 2006 0924.
2. Speed up linker on .o files with debug info on linkonce sections.
PR 3111.
3. Added x86-64 PE support.
4. Fix objcopy/strip on .o files with section groups. PR 3181.
5. Fix "ld --hash-style=gnu" crash with gcc 3.4.6. PR 3197.
6. Fix "strip --strip-debug" on .o files generated with
"gcc -feliminate-dwarf2-dups". PR 3186.
7. Fix "ld -r" on .o files generated with "gcc -feliminate-dwarf2-dups".
PR 3249.
8. Add --dynamic-list to linker to make global symbols dynamic.
9. Fix magic number for EFI ia64. PR 3171.
10. Remove PT_NULL segment for "ld -z relro". PR 3015.
11. Make objcopy to perserve the file formats in archive elements.
PR 3110.
12. Optimize x86-64 assembler and fix disassembler for
"add32 mov xx,$eax". PR 3235.
13. Improve linker diagnostics. PR 3107.
14. Fix "ld --sort-section name". PR 3009.
15. Updated an x86 disassembler bug. PR 3000.
16. Various updates for PPC, ARM, MIPS, SH, Xtensa.
17. Added Score support.
Changes from binutils 2.17.50.0.2:
1. Update from binutils 2006 0715.
2. Add --hash-style to ELF linker with DT_GNU_HASH and SHT_GNU_HASH.
3. Fix a visibility bug in ELF linker (PR 2884).
4. Properly fix the i386 TLS linker bug (PR 2513).
5. Add assembler and dissassembler support for Pentium Pro nops.
6. Optimize x86 nops for Pentium Pro and above.
7. Add -march=/-mtune= to x86 assembler.
8. Fix an ELF linker with TLS common symbols.
9. Improve program header allocation in ELF linker.
10. Improve MIPS, M68K and ARM support.
11. Fix an ELF linker crash when reporting alignment change (PR 2735).
12. Remove unused ELF section symbols (PR 2723).
13. Add --localize-hidden to objcopy.
14. Add AMD SSE4a and ABM new instruction support.
15. Properly handle illegal x86 instructions in group 11 (PR 2829).
16. Add "-z max-page-size=" and "-z common-page-size=" to ELF linker.
17. Fix objcopy for .tbss sections.
Changes from binutils 2.17.50.0.1:
1. Update from binutils 2006 0526.
2. Change the x86-64 maximum page size to 2MB.
3. Support --enable-targets=all for 64bit target and host (PR 1485).
4. Properly update CIE/FDE length and align section for .eh_frame
section (PR 2655/2657).
5. Properly handle removed ELF section symbols.
6. Fix an ELF linker regression introduced on 2006-04-21.
7. Fix an segfault in
Re: GCC 4.3 Platform List
Mark Mitchell wrote: I have now reviewed the suggestions. Here is the mail that I plan to recommend to the SC. (Of course, I can't guarantee what the SC will do with it.) I've tried to take into account most of the feedback. However, I've tried to note all of these suggestions in my draft mail so that the SC will see all of the ideas, even those with which I don't agree. Please let me know if your recommendation isn't reflected in this mail, either in the "Recommendations" or in the "Other Suggestions" section -- that means that I unintentionally overlooked it. And, if you would like to address the SC directly, please let me know and I will be happy to pass along your message. Recommendations === I think that we should update the list of primary and secondary platforms for GCC 4.3. This section has my personal recommendations, based on feedback from the GCC developer mailing list. In the next section are other suggestions that I received, but which I don't personally endorse. Primary Platforms - * arm-eabi * i386-unknown-freebsd * i686-pc-linux-gnu * i686-apple-darwin * mipsisa64-elf * powerpc64-unknown-linux-gnu * sparc-sun-solaris2.10 * x86_64-unknown-linux-gnu Secondary Platforms --- * hppa2.0w-hp-hpux11.23 * powerpc-ibm-aix5.2.0.0 * powerpc-apple-darwin * i686-pc-cygwin * i686-mingw32 * ia64-unknown-linux-gnu Other Suggestions = Here are the suggestions that I'm not endorsing personally, but which I would like to pass along: * AVR as a secondary target * Replace the MIPS "bare metal" platform with a GNU/Linux platform. * Make both Intel and PowerPC Darwin primary platforms. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Documentation for loop infrastructure
Sebastian Pop <[EMAIL PROTECTED]> wrote on 08/09/2006 18:04:01:
> Ira Rosen wrote:
> >
> > > Here is the documentation for the data dependence analysis.
> >
> > I can add a description of data-refs creation/analysis if it is useful.
> >
>
> That's a good idea, thanks.
>
> Sebastian
Here it is.
Ira
> The data references are discovered in a particular order during the
> scanning of the loop body: the loop body is analyzed in execution
> order, and the data references of each statement are pushed at the end
> of the data reference array. Two data references syntactically occur
> in the program in the same order as in the array of data references.
> This syntactic order is important in some classical data dependence
> tests, and mapping this order to the elements of this array avoids
> costly queries to the loop body representation.
Three types of data references are currently handled: ARRAY_REF,
INDIRECT_REF and COMPONENT_REF. The data structure for the data reference
is @code{data_reference}, where @code{data_reference_p} is a name of a
pointer to the data reference structure. The structure contains the
following elements:
@itemize
@item @code{base_object_info}: Provides information about the base object
of the data reference and its access functions. These access functions
represent the evolution of the data reference in the loop relative to
its base, in keeping with the classical meaning of the data reference
access function for the support of arrays. For example, for a reference
@code{a.b[i][j]}, the base object is @code{a.b} and the access functions,
one for each array subscript, are:
@[EMAIL PROTECTED], + [EMAIL PROTECTED], @{j_init, +, [EMAIL PROTECTED]
@item @code{first_location_in_loop}: Provides information about the first
location accessed by the data reference in the loop and about the access
function used to represent evolution relative to this location. This data
is used to support pointers, and is not used for arrays (for which we
have base objects). Pointer accesses are represented as a one-dimensional
access that starts from the first location accessed in the loop. For
example:
@smallexample
for i
for j
*((int *)p + i + j) = a[i][j];
@end smallexample
The access function of the pointer access is @[EMAIL PROTECTED], + [EMAIL
PROTECTED] relative
to @code{p + i}. The access functions of the array are
@[EMAIL PROTECTED], + [EMAIL PROTECTED] and @[EMAIL PROTECTED], +, [EMAIL
PROTECTED] relative
to @code{a}.
Usually, the object the pointer refers to is either unknown, or we can’t
prove that the access is confined to the boundaries of a certain object.
Two data references can be compared only if at least one of these two
representations has all its fields filled for both data references.
The current strategy for data dependence tests is as follows:
If both @code{a} and @code{b} are represented as arrays, compare
@code{a.base_object} and @code{b.base_object};
if they are equal, apply dependence tests (use access functions based on
base_objects).
Else if both @code{a} and @code{b} are represented as pointers, compare
@code{a.first_location} and @code{b.first_location};
if they are equal, apply dependence tests (use access functions based on
first location).
However, if @code{a} and @code{b} are represented differently, only try
to prove that the bases are definitely different.
@item Aliasing information.
@item Alignment information.
@end itemize
> The structure describing the relation between two data references is
> @code{data_dependence_relation} and the shorter name for a pointer to
> such a structure is @code{ddr_p}. This structure contains:
