This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC/RFT] Tree-level lowering of generic vectors, part 2
- From: Paolo Bonzini <paolo dot bonzini at polimi dot it>
- To: David Edelsohn <dje at watson dot ibm dot com>
- Cc: Paolo Bonzini <bonzini at gnu dot org>, Alan Modra <amodra at bigpond dot net dot au>, GCC Development <gcc at gcc dot gnu dot org>
- Date: Mon, 09 Aug 2004 08:45:02 +0200
- Subject: Re: [RFC/RFT] Tree-level lowering of generic vectors, part 2
- References: <40FE496F.9090608@polimi.it> <200408052014.i75KE5D32016@makai.watson.ibm.com> <41133FEC.6050608@polimi.it> <200408061922.i76JMcD34328@makai.watson.ibm.com> <20040807143640.GL12879@bubble.modra.org> <41162387.3090101@gnu.org> <200408082008.i78K8jD29596@makai.watson.ibm.com>
I am not disagreeing with you for variable size vectors
There are no variable sized vectors.
I want GCC to be
consistent and use the same model for vector registers: if the target
provides V4SF, then use a pair of vector registers for V8SF and four for
V16SF.
That's fine. Only, I do not know (yet) how to do it.
I think supporting arbitrary vectors within GCC is great. If you
want to support arbitrary size vectors, then follow the precedent in GCC
and call it an arbitrary size vector type. If I refer to an object larger
than the types that GCC natively supports, GCC throws it in BLKmode. Why
don't you do the same?
I do the same. Large vectors are BLKmode -- the problem is the rs6000
back-end expects all BLKmode types to be of an aggregate type.
If instead of allowing v16sf on a platform that doesn't natively support
it, you called it a variable sized type
I called it a BLKmode type whose int_size_in_bytes is 16, not -1.
My point is that you are making this much more complicated and
intrusive than it needs to be. I am arguint that types that correspond to
paired registers should be passed in paired registers.
That's fine with me, but I have not yet delved into the backend enough
to understand how to do it.
Treat it as variable sized vector types,
which matches you true goal, and then the ABI problems evaporate.
It seems we do have consensus on the ABI. You exposed your idea, Alan
agreed, I said I don't care. :-) It remains to implement it.
The patch at http://gcc.gnu.org/ml/gcc-patches/2004-07/msg02197.html is
a first step -- it makes 16-byte vector ABIs independent of the
availability of AltiVec (because they have BLKmode if AltiVec is
unavailable and a vector mode otherwise). Is it ok? From there, we can
go on incrementally.
Paolo