Re: [discuss] x86-64 abi, regarding vector types

[Paul Schlie <schlie at comcast dot net>]

>Jan Hubicka wrote in response to:
>
>> Since gcc 3.3 or so, gcc has attempted to support vector types
>> on all targets, with varying degrees of success.  For gcc 4.0,
>> this support was rewritten, and in the process is exposing ABI
>> incompatibility problems between gcc versions. ...
>
> We are hitting here the problem with specifying non-C rules in C ABI :)
> When mentioning the aggregates being either structures or arrays if
> passed by values, I would just mention that vector types of sizes
> different than 8 and 16 are threat same way as arrays, perhaps. I will
> give it more tought tomorrow.

Although commenting on an issue somewhat broader in scope; in general, it
would seem nice (if not arguably prudent) to consider treating all types
uniformly (as there seems to be no valid logical reason to treat any type,
including "lesser than int sized" scalar types for example, any differently
than their vectorized counterparts or visa-veras), as although C may specify
promotion rules for example, they need not be explicitly followed to yield
logically compliant behavior.

As arithmetic and logical semantics truly define when and if type promotion
is required based on the precision requirements of the assigned/side-effect
results of any expression bound by modular binary arithmetic.  Thereby any
array and/or vector of scalar values may be grouped as a SIMD operation
partitioned at any the natural binary boundary which the target may support
(ranging from some binary fraction, to multiple of the operand's precision),
utilizing equivalent semantics regardless of its potential vectorization.

Where in net effect all operations, and correspondingly it's operands
precision requirements are truly specified by it's targets precision
requirements, nothing else. i.e therefore all operands should have
equivalent semantics:

- operands (vectorized or not), may be accessed by reference, or by value;
by one to pow2-N per logical access (determined by the targets capacity
(i.e. not specified explicitly in source code).

- no lesser than int wide integer, enum, or bool operands need ever be
implicitly promoted by the front or middle ends, vectorized or not.

- front/middle ends need only ascertain the minimum precision of the
operations required, as a function of it's targets precision requirements,
in conjunction with it's true source operand precision, and semantics
of the operations itself. (the present often needless default promotion of
smaller then int wide scalar operands for example typically only results in
the need for otherwise unnecessary subsequent operation/operand precision
optimization, often potentially affecting their vectorisable efficiency)

- where then the middle/back end may then determine if any operands need
to be implicitly promoted to satisfy the targets machine description
requirements, and then correspondingly grouped (i.e. loops literally
unrolled, etc.) to achieve greatest target efficiency.

I know it's a lot easier to state than to implement, but it seems that the
simplifying benefits of adopting such a strategy may likely worth the
effort longer term (and also improve the target neutrality of the compiler).

Might such an approach be worthy of consideration, and working incrementally
towards; or is it possibly too inconsistent with GCC's present approach?
(or possibly already been considered and subsequently rejected?)