'''~+As of August 2008, the tuples branch has been incorporated into mainline.  This code will be released with GCC 4.4.+~'''


= GIMPLE Tuples =
This is a new internal representation for GIMPLE.  It is is a tuple-like representation instead of the current notion of treating everything as a 'tree'. So `tree`-s are front-end representations, and tuples (i.e. `gimple`-s in the C code) are the middle-end representation (different from `tree`-s). Middle-end passes are handling `gimple` tuples. Some internal fields inside  `gimple` tuples are `tree`-s.  Discussions on the proposed approach can be found here:

 * http://gcc.gnu.org/ml/gcc/2006-02/msg00622.html
 * http://gcc.gnu.org/ml/gcc/2006-06/msg00350.html
 * http://gcc.gnu.org/ml/gcc/2007-03/msg01126.html
 * http://gcc.gnu.org/ml/gcc/2007-04/msg00290.html

The tuple branch [[http://gcc.gnu.org/ml/gcc/2008-07/msg00549.html|has just been merged]] (July, 27-28th, 2008) into GCC trunk (rev.138207).

== API Documentation ==

This [[http://docs.google.com/Doc?id=dgfkmttj_107hcr98sg3|document]] describes the proposed design.  All the work is being done on the SVN branch {{{gimple-tuples-branch}}}.  The document is still under construction and will change as the API evolves.

== Branch status (updated 2008-07-16) ==
 * The branch bootstraps with all primary languages.
 * Major missing functionality includes:
   * One unconverted pass ({{{pass_ipa_matrix_reorg}}}).
 * Preliminary memory and compile-time testing show promising results: http://gcc.gnu.org/ml/gcc-patches/2008-06/msg00353.html.

To build the branch:

{{{
$ cd <bld>
$ <src>/configure
$ make
}}}
When submitting patches, please make sure that your patch bootstrap as above and you do not have new regressions against the failures in the base branch.

== Plan ==
 1. Convert disabled passes.
  * '''[razya]''' {{{pass_ipa_matrix_reorg}}}
 1. No regressions in {{{make check}}} w.r.t trunk.
 1. Convert [[http://gcc.gnu.org/gcc-4.3/criteria.html|primary platforms]]
  * i386-unknown-freebsd
  * sparc-sun-solaris2.10
 1. Convert [[http://gcc.gnu.org/gcc-4.3/criteria.html|secondary platforms]]
  * hppa2.0w-hp-hpux11.11
  * powerpc-ibm-aix5.2.0.0
  * powerpc-apple-darwin
  * i686-pc-cygwin
  * i686-mingw32
  * s390-linux-gnu
 1. Convert secondary languages
  * Ada

== Cleanups and other TODOs ==
=== Add as needed and claim the ones you are working on ===
 1. Remove {{{fallback}}} in {{{gimplify_expr}}} and figure it out from the predicate
 1. Whenever possible, convert {{{buildN/gimplify_and_add}}} calls into {{{build_gimple_*/gimple_add}}}, to avoid the overhead of calling the gimplifier unnecessarily.
 1. Make the sequences a flat array instead of a double-linked list.  Use some dynamic array representation that supports insertion/removal in the middle efficiently.
 1. Fix all the {{{FIXME tuples}}} in the code
 1. Stop the gimplifier from modifying the input tree.  Currently, rewriting the input is used when the caller wants a GIMPLE operand to be returned.  It is also used during gimplification by the helper functions to simplify the input tree as they go.  If we didn't need this, we could do away with the need to unshare all the trees when gimplifying full functions.
 1. Replace {{{fold_defer_overflow_warnings}}}/{{{fold_undefer_overflow_warnings}}} with a tagging scheme.  When fold() returns a result that has overflown, tag the result and emit the warning only when the result is put back into the IL.
 1. Move most of the folding code in {{{tree-ssa-ccp.c}}} into {{{gimple-fold.c}}}.
 1. Convert builtin expanders to run on gimple tuples prior to conversion to trees, or otherwise eliminate their callbacks into the tuples world.
 1. Modify {{{GIMPLE_CALL}}} builders to pass the LHS of the call to {{{gimple_build_call_*}}}.