>
> Substantial progress has been made towards GCC 4.0 over the past
> several weeks. There are now 103 open regressions targeted at 4.0,
> including 13 wrong-code bugs, and 31 rejects-valid or
> ice-on-valid-code bugs.
>
> That means that we are very nearly at the point where we can create
> the GCC 4.0 release branch.
>
> However, before that happens, it is important that we have a coherent
> strategy for GCC 4.1. There are a number of major branches (and
> perhaps done on work that is not on a branch) that people will want to
> integrate, and we must do that in an orderly fashion.
>
> Therefore, we will use the same proposal-based procedure that we used
> (late) in the GCC 4.0 timeframe. If you have already completed, or
> are planning to complete, a substantial project that you would like to
> include in GCC 4.1, please send me the following information:
>
* Project Title: Autovectorization enhancements
* Project Contributors:
Ira Rosen, Devang Patel, Dorit Naishlos, Keith Besaw.
* Dependencies: None.
* Description and Delivery Dates
1- Cleanups and improvement of existing functionality
1.1 Incrementally preserve ssa form when vectorizing (Keith)
- Description: define the virtual operands of newly
generated vector statements so that the ssa
form is preserved.
- Benefit: avoid call to rewrite_into_ssa
- Date: already in autovect; can be submitted when
4.1 opens.
1.2 Incrementally preserve loop-closed form when vectorizing (Dorit)
- Description: maintain loop-closed form when doing
loop-peeling in the vectorizer.
- Benefit: avoid call to rewrite_into_loop_closed_ssa
- Date: already in autovect; can be submitted when 4.1 opens.
1.3 Improvements to peeling for alignment (Dorit)
- Description: handle known-misalignment case more
efficiently; detect accesses with the same alignment.
- Benefits: improved code quality; increased vectorization
potential (for targets that don't support misalignment).
- Date: already in autovect; can be submitted when 4.1 opens.
1.4 Consider dependence distance in the vectorizer (Devang)
- Description: allow vectorization in the presence of
dependency if the dependence distance is safe.
- Benefits: more loops vectorized.
- Date: already in autovect; can be submitted when 4.1 opens.
1.5 Externalize generic parts of dataref analysis (Ira)
- Description: Make available generic parts of the dataref
analysis to other passes.
- Benefits: Share functionality with other passes.
- Date: By end of March.
For all of the above:
- parts of the compiler: tree-vectorizer.c
(and tree-data-ref.c for item 1.5)
- risks: More loops vectorized is more potential for problems.
2- New functionality
2.1 Loop versioning for alignment (Keith)
- Description: generate a vector version and a non-vector
version of a loop with entry controlled by alignment tests
- Benefits: vectorize loops where alignment is unknown at
compile time
- Parts of the compiler: tree-vectorizer.c
- Risks: code bloat
- Date: already in autovect; can be submitted when 4.1 opens.
2.2 Reduction support (Dorit)
- Description: vectorize computations like 's+=a[i]'
- Benefits: increase potential for vectorization
- Parts of the compiler: tree-vectorizer.c, new tree-codes/optabs,
target specific files (.md).
- Risks: more loops vectorized is more potential for problems.
- Date: By end of March.
2.3 Vectorization of conditional code (Devang)
- Description: Vectorize loops with conditional code.
- Benefits: Increase potential for vectorization.
- Parts of the compiler: tree-vectorizer.c, config/rs6000.c
(other back ends may need some work to support this).
- Risks: more loops vectorized is more potential for problems.
- Date: Already in autovect; can be submitted when 4.1 opens.
3- Additional items we're considering (or planning to do but not sure when)
include:
3.1 #pragma support to guide autovectorizer (Devang)
- Description: Allow user to guide compiler when to vectorize
and when not to vectorize particular loop using #pragma.
Intel compiler provides similar functionality.
- Benefits: Give user more choices. It also helps vectorizer
when it can't prove there is no data dependency but user
knows that.
- Parts of the compiler: ?
- Risks: ?
- Date: ?
3.2 Loop versioning to eliminate data dependence (Keith)
- Description: generate a vector version and a
non-vector version of a loop with entry
controlled by data dependence tests.
- Benefits: vectorize loops where data dependence
is unknown at compile time.
- Parts of the compiler: tree-vectorizer.c
- Risks: code bloat
- Date: July?
3.3 Misaligned stores support (Dorit/Ira)
- Description: Support misaligned stores using the
tree-codes we agreed on last year.
- Benefits: Increase potential for vectorization.
- Parts of the compiler: tree-vectorizer.c,
tree.def etc (new tree-codes), .md files.
- Risks: Misaligned stores incur an overhead
- Date: ?
3.4 SLP in loops (Ira)
- Description: straight-line code vectorization. Focus on
loops, to exploit intra-iteration parallelism.
- Benefits: vectorize unrolled loops.
- Parts of the compiler: vectorizer.
- Risks: Different vectorization algorithm than what we
have now (so we're going to try two vectorization
schemes which may affect compile time).
- Date: ?
3.5 Outer-loop vectorization (Dorit)
- Description: vectorize certain forms of doubly-nested loops.
- Benefit: vectorize when the parallelism is in the outer-loop
and we can't (or don't want) to apply loop-interchange.
- Parts of the compiler: tree-vectorizer.c
- Risks: more loops will be considered for vectorization.
- Date: ?
Ira, Devang, Keith & Dorit.
> * Project Title
>
> * Project Contributors
>
> * Dependencies
>
> Any other projects which must be integrated before your project can
> be integrated.
>
> * Delivery Date
>
> When will your project be ready for integration? (Be conservative;
> I will consider dropping projects that are available past their
> delivery date.)
>
> * Description
>
> Describe the project *in detail*.
>
> What will you be doing?
>
> What parts of the compiler will be modified?
>
> What will the benefits of your change be? (Be specific -- for
> example, if you will be improving code quality, indicate what kind
> of code, and, if possible, how great the improvement will be.)
>
> What risks do you foresee? (If you say "none", you'll be asked to
> resubmit...) What will you be doing to mitigate those risks?
>
> I'll synthesize this information and make decisions about schedules
> for 4.1 once I have the proposals in hand.
>
> To that end, please submit your proposal(s) by February 17th. Late
> proposals will still be considered. In fact, there's nothing to
> prevent us from including work conceived developed later in the cycle,
> if that's appropriate. So, the February 17th date is not a drop-dead
> deadlin for 4.1 material in any way.
>
> But, I would like to get a sense of what projects are already out
> there, so that we can start bringing them into GCC 4.1. By staging
> the integration, we can take some time to stabilize after each major
> contribution.
>
> I will create the GCC 4.0 branch on February 24th, after posting
> information about initial GCC 4.1 development, based on the proposals
> I have received by the 17th. Based on current progress, my
> expectation is that the branch will be in very good shape by then.
>
> Therefore, my current expectation for a GCC 4.0 release date is April
15th.
>
> --
> Mark Mitchell
> CodeSourcery, LLC
> [EMAIL PROTECTED]
