This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GCC 4.0 Status Report (2005-02-03)





>
> 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
> mark@codesourcery.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]