Altivec discussion summary, future direction

[Geoff Keating <geoffk at desire dot geoffk dot org>]

So, we've had some discussion about the proposed Altivec changes, and
I thought I'd summarise the discussion and suggest a way to proceed
from here.

I'll organize the summary under each thing that the patch did.

> (1) Adds a '-faltivec' switch (for Darwin targets only), which is
> similar to '-maltivec' except that the <altivec.h> header gets pulled
> in automatically as well.

There didn't seem to be any comments on this.

> (2) Adds support for context-sensitive keywords. This is
> accomplished via what I call "conditional macros", whereby a
> predicate is evaluated to decide whether a macro (in our case,
> "vector", "pixel", etc.)  should be expanded or not. This is
> controlled by a target hook, and is turned off completely unless you
> specify '-maltivec' or '-faltivec'.

There were objections to this.

- One class of comments was against context-sensitive keywords in
  general, saying that they're usually a bad idea and are difficult
  to make reliable.

- Another class was not against it in principle, or didn't comment on
  the overall desirability, but pointed out that the current patch is
  way too intrusive.

> (3) Adds support for 'vector pixel' and 'vector bool ...' types as
> _distinct_ from 'vector unsigned ...' (This was missing from
> AldyVec), and adds canonical name-mangling for the AltiVec types.

There didn't seem to be any comments on this.  

> (4) Adds support for treating comma expressions, when cast to a
> vector type, as vector initializers (e.g., "(vector signed int)(1,
> 2, 3, 4)"), as the Apple/Motorola AltiVec syntax requires. The
> AldyVec array-style initializers ("{1, 2, 3, 4}") are supported as
> well.

There were very significant objections to this, against the principle
of the extension, pointing out that it was badly designed, not in
keeping with C99, etc.  It was said that the last time this was proposed
this was also rejected.

> (5) Adds support for the -W[no-]altivec-long-deprecated flag (for
> Darwin targets only) to optionally suppress warnings about uses of
> 'vector long ...'  types.

There were no comments on this.


OK, so given those comments, where to go from here?

I think the best way forward is to split this patch into three parts:

1. Items from (1), (3), and (5), which didn't get significant
   commentary.  I think this patch, as a standalone item, will get
   some discussion.  I'm hoping that this patch will be almost all
   rs6000-specific or Darwin-specific, and it should be able to go
   into 3.5 (maybe even 3.4 if it seems safe---the type part of the
   patch is a genuine bug fix, Aldy's work was supposed to comply with
   the PIM).

2. Item (2), the context-sensitive vector keyword, as a standalone
   patch, as simple and clean as possible, and including clear and
   precise documentation on exactly when 'vector' gets treated as a
   keyword.  This patch might be integrated into the mainline, if it's
   sufficiently clean; if not, it can go into contrib/ and Apple will
   keep it as a local patch.

3. Item (4), the () notation, as a standalone patch, designed to be
   easy to keep up-to-date.  This will not go into FSF GCC, it will go
   into contrib/ and Apple will have it as a local patch.  Hopefully,
   we can encourage our users to move away from this to a {} notation;
   I don't think this would be particularly difficult.  I'd like to
   also see this patch include a warning that this syntax is
   deprecated, so that users can find instances where the syntax is
   used.

-- 
- Geoffrey Keating <geoffk@geoffk.org>