Re: [PATCH]: Handle vector modes in genopinit.c, c-typeck.c

[Daniel Berlin <dan at cgsoftware dot com>]

On Thursday, November 29, 2001, at 01:15  PM, Joseph S. Myers wrote:

> On Thu, 29 Nov 2001, Daniel Berlin wrote:
>
>> I want to know if it's even acceptable as a principle before I attempt
>> to write up docs.
>
> Acceptability depends on what exactly you're trying to do, which depends
> on the docs.
>
>>>   What operations are allowed?  (For example, do you
>>> allow unary minus - if not, why not?)
>> The same operations that are allowed on integers and floats would be
>> allowed on vectors of integers and vectors of floats.
>
> Exact list please.  For example, do you allow the << and >> operators on
> vectors of integers
Yes.

> If so, what do they mean?

The result of applying the shift operator to each individual element.
> Shifts of individual elements?
Yes.

>   What do logic operations such as ! mean on vectors?

It returns a vector of the logical operation applied to each element of 
the two vectors, elementwise in the case of binary operations.
In the case of unary operations, it's simply the operation applied to 
each vector element.

>
> The C type system is complicated.  C99 complicated it further with 
> complex
> types.  I won't ask right now for the rules for the vector types

>  to be put
> in suitable form for input to a theorem-proving system, but it needs to 
> be
> absolutely clear exactly what can be done and what it means, and the
> meanings need to be clear to readers of the code.

Which is why in general, unary vector operations perform the exact same 
operation one would get if you applied the operation seperately to each 
element
Where there is considerable ambiguity, we'll simply not allow the 
operation.
So please list the ones *you* (or anyone else for that matter) find 
ambiguous, and we'll see if they really are.
If they are, they simply won't be allowed through non-intrinsics.

>
>>> Must the operands be the same type?
>> If they normally must be of the same type for the underlying type of 
>> the
>> vector, then yes.
>> IE if float - int is not allowed, vector float - vector int is not
>> allowed.
>
> But float - int is allowed - the arguments both get promoted to float.
I was using it as an example.
I know perfectly well float - int is allowed.
>
> What promotions apply to the vectors?  (Note that arithmetic on char 
> will
> promote it to int, but you might not want operations on vectors of char 
> to
> promote them to vectors of int.)

That would make for confusing semantics. If performing arithmetic on 
char causes promotion to int, and you don't want the same to apply to 
your vector, you use an intrinsic to specify this exactly.


>
>> This i've not thought much about yet. I'd rather keep to vector
>> operations at the present, rather than try to figure out what ops are
>> allowed between vector and scalar, and their semantics.
>
> I don't think it's particularly clear to a reader of a program what *
> means on vectors, either.

That is okay, if it's really that ambiguous, we'll just not allow it.

>
>> Right now, you can only do this with intrinsics.
>> But the intrinsics expand to the exact same RTL that you'd get if you
>> allowed normal operations on that mode in the type checker.
>> So why should you need the intrinsics to say this?
>
> Some RTL and tree operations can already only be obtained by built-in
> functions (target-independent functions, but with insn patterns only
> provided on some targets).
Sure.
>
>> Not yet, but i will.
>> As I said, i'm just testing the waters, not looking for approval 
>> (except
>
> In that case, send docs, not code.
>
Okey, i'll do so.

> --
> Joseph S. Myers
> jsm28@cam.ac.uk