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: gimple vs gimple_seq in 4.8 trunk


On Fri, May 11, 2012 at 02:12:32PM +0200, Michael Matz wrote:

> On Fri, 11 May 2012, Basile Starynkevitch wrote:
> 
> > However, the type gimple_seq still appears in a lot of source files 
> > (mostly gcc/gimple*.c & gcc/tree*.c)
> > 
> > Is this intended, or is this a temporary situation, and 
> > further patches would remove all occurrences of gimple_seq everywhere?
> 
> I'm personally undecided.  Retaining gimple_seq would make it possible to 
> change the implementation of sequences to something else relatively 
> easily.  


Then perhaps we should better have something like

  /* a single GIMPLE statement. 
     Take care to use the gimple type when you are thinking of a single statement 
     only, e.g. to retrieve its operands. */
  typedef union gimple_statement_d *gimple;

  /* a sequence of GIMPLE statements.
     Use the gimple_seq type when thinking of a sequence of statements. 
     The gimple_seq might have a different representation some day (and used to have one).
    */
  typedef union gimple_statement_d *gimple_seq;

I believe the above is more understandable than a "typedef gimple gimple_seq;"
which brings some assymetry in the code.



If coding in C++, we could have
  typedef class Gimple *gimple;
  typedef class GimpleSeq *gimple_qeq;
  
And if we coded in C++, we would dare having

  class Gimple_statement_data {
    //....
  };

  class Gimple : public Gimple_statement_data {
    //....
  }
  
  class GimpleSeq : public Gimple_statement_data {
    //....
  };

I really think that it is important to decide *now* 
if gimple and gimple_seq are conceptually different
(and to document and comment that) or the same. 

As you suggest, if we don't make a clear statement in a comment 
and in documentation, things will surely degrade with time.

Cheers.
-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***


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