From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27981 invoked by alias); 12 Feb 2003 22:26:53 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 27973 invoked from network); 12 Feb 2003 22:26:52 -0000 Received: from unknown (HELO linuxpc1.lauterbach.com) (213.70.137.66) by 172.16.49.205 with SMTP; 12 Feb 2003 22:26:52 -0000 Received: (qmail 12728 invoked by uid 82); 12 Feb 2003 22:26:51 -0000 Received: from Franz.Sirl-kernel@lauterbach.com by linuxpc1 by uid 80 with qmail-scanner-1.15 (inocmd32: virsig.da0 23.58.28 . spamassassin: 2.43-cvs. Clear:. Processed in 0.765341 secs); 12 Feb 2003 22:26:51 -0000 Received: from dsl-213-023-062-071.arcor-ip.net (213.23.62.71) by linuxpc1.lauterbach.com with SMTP; 12 Feb 2003 22:26:50 -0000 From: Franz Sirl To: Richard Henderson Subject: Re: Altivec + 16 byte alignment Date: Wed, 12 Feb 2003 22:31:00 -0000 User-Agent: KMail/1.5 Cc: John David Anglin , gcc@gcc.gnu.org, gianni@scaramanga.co.uk References: <200302111725.h1BHP0rt016722@hiauly1.hia.nrc.ca> <200302122207.54496@enzo.bigblue.local> <20030212214621.GE29744@redhat.com> In-Reply-To: <20030212214621.GE29744@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200302122326.49019@enzo.bigblue.local> X-SW-Source: 2003-02/txt/msg00872.txt.bz2 On Wednesday 12 February 2003 22:46, Richard Henderson wrote: > On Wed, Feb 12, 2003 at 10:07:54PM +0100, Franz Sirl wrote: > > ... and the stack pointer is kept aligned (to 256 bits) by > > independent code as well > > Is this 256 bits ABI mandated? I.e. will a non-gcc ppc > compiler maintain this alignment as well? Yep, ABI mandated, 256 bits for SYSV, 128 bits for EABI. > If yes, then STACK_ALIGNMENT is set too low. You should > advertise what you have. If no, then calling between two > functions compiled with different compilers will not > preserve the 256 bit alignment you claim. STACK_ALIGNMENT? I can't find that. Closest I can find is MIPS_STACK_ALIGN. Did you think of some other macro? Sounds promising though. Maybe part of the confusion stems from the overloaded meaning of STACK_BOUNDARY, sometimes it means "alignment needed for the stack pointer", sometimes "maximum alignment of objects in the frame" or similar it seems. Hmm, do we have a function like get_frame_max_object_align()? Then each backend could adjust alignment of the frame vs. the alignment of the stackpointer as required. > There are passes in gcc, particularly combine, that look > at the advertised alignment for a pointer and know that > the low bits are zero, and perform optimizations based on > this. If the alignment doesn't exist, the optimizations > produce incorrect results. But this certainly isn't a problem if we _increase_ STACK_BOUNDARY like I suggested, or? Franz.