This is the mail archive of the gcc-patches@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: [patch] set -mabi=altivec with -ftree-vectorize


On Tue, Jul 31, 2007 at 08:02:12AM -0400, David Edelsohn wrote:
> >>>>> Daniel Jacobowitz writes:
> 
> Daniel> Is that really a good idea?  It makes sense that -mabi= is an
> Daniel> ABI-changing option, but I'd be surprised if adding -ftree-vectorize
> Daniel> changed the ABI.
> 
> Daniel,
> 
> 	Without automatically enabling -mabi=altivec, GCC silently
> generates wrong code.
> 
> 	The only other option I see is to error that -mabi=altivec needs
> to be enabled with -ftree-vectorize -maltivec for the targets that do not
> enable it automatically.  Generating wrong code needs more than a warning.
> Do you think that is a better solution?

I didn't realize from the patch that wrong code was involved.  I
certainly agree that silently generating wrong code is not an option
:-)  You'll already know most of this message, but let me outline it
so that everyone's looking from the same side.

Here's what goes wrong in the test case from that patch (- is
-maltivec, + is -maltivec -mabi=altivec):

 main:
        stwu 1,-16(1)
        mflr 0
-       vxor 0,0,0
        stw 0,20(1)
        bl set
        lis 9,a@ha
        la 9,a@l(9)
+       vxor 0,0,0
        addi 11,9,48
        stvx 0,0,9
        stvx 0,0,11

-ftree-vectorize causes "set" to use AltiVec registers, and clobber
v0.  Then the vector code in main (an inlined memset) uses the
clobbered v0.  -ftree-vectorize will make this problem much more
likely, but there's no dependency on it; if you wrote the set and
memset using AltiVec builtin functions, the same thing could go
wrong.  The problem is using just -maltivec.

With -mabi=altivec, v0 through v19 are call-used (call-clobbered,
caller-saved).  Without -mabi=altivec, no AltiVec registers are saved
on the stack (ref: first_altivec_reg_to_save).  Saving and restoring
them would be a bit inefficient, due to the inadequate stack
alignment.  But they're not mark call-used either, so GCC assumes it
can use them.

In my opinion, if we are not going to use the AltiVec ABI, we should
either not use the AltiVec registers or else save and restore them
all.  Would it work to mark them all call-used for -maltivec, and
then save them to the stack by allocating eight bytes extra and
masking the stack pointer for sufficient alignment?  It wouldn't even
be that inefficient.  Of course it would be slower than what we have
today where we don't even bother to save them.  But I don't see how
it's legitimate to use the current -maltivec in anything but a leaf
function, which is undocumented and pretty bad.

-- 
Daniel Jacobowitz
CodeSourcery


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