From owner-svn-src-all@FreeBSD.ORG Sun Nov 11 15:01:52 2012 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 19BB775B; Sun, 11 Nov 2012 15:01:52 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail04.syd.optusnet.com.au (mail04.syd.optusnet.com.au [211.29.132.185]) by mx1.freebsd.org (Postfix) with ESMTP id 9A52F8FC08; Sun, 11 Nov 2012 15:01:51 +0000 (UTC) Received: from c122-106-175-26.carlnfd1.nsw.optusnet.com.au (c122-106-175-26.carlnfd1.nsw.optusnet.com.au [122.106.175.26]) by mail04.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id qABF1lfe024758 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Nov 2012 02:01:49 +1100 Date: Mon, 12 Nov 2012 02:01:47 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Dimitry Andric Subject: Re: svn commit: r242835 - head/contrib/llvm/lib/Target/X86 In-Reply-To: <509FB35F.1010801@FreeBSD.org> Message-ID: <20121112014417.O1675@besplex.bde.org> References: <201211091856.qA9IuRxX035169@svn.freebsd.org> <509F2AA6.9050509@freebsd.org> <20121111214908.P938@besplex.bde.org> <509FB35F.1010801@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-Cloudmark-Score: 0 X-Optus-Cloudmark-Analysis: v=2.0 cv=JdTkNj2V c=1 sm=1 a=B4V2Pwk6IZ0A:10 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=Bex9lGB9SJoA:10 a=e1J0XFQeW5S4DCYVn3QA:9 a=CjuIK1q_8ugA:10 a=bxQHXO5Py4tHmhUgaywp5w==:117 Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, Nathan Whitehorn , Bruce Evans X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 15:01:52 -0000 On Sun, 11 Nov 2012, Dimitry Andric wrote: > On 2012-11-11 12:53, Bruce Evans wrote: >> >> I'm not sure if either of us knows exactly what this does, but I like >> this change. clang does stack alignment correctly, so it doesn't need >> the gcc pessimization of aligning in the caller. clang aligns in the Apparently we did know. >> ... >> alignment. gcc's alignment in callers doesn't even work, because gcc >> assumes that it is enough and never does it in callees even when it >> is necessary: >> >> auto int32_t foo[8] __aligned[32]; >> >> gcc fails to do the necessary alignment. clang does it. >> >> auto int32_t foo[8] __aligned[16]; >> >> Both gcc and (hopefully only without the above fix) clang fail to do the >> necessary alignment. > > It works just fine now with clang. For the first example, I get: > > pushl %ebp > movl %esp, %ebp > andl $-32, %esp > > as prolog, and for the second: > > pushl %ebp > movl %esp, %ebp > andl $-16, %esp Good. The andl executes very fast. Perhaps not as fast as subl on %esp, because subl is normal so more likely to be optimized (they nominally have the same speeds, but %esp is magic). Unfortunately, it seems to be impossible to both align the stack and reserve some space on it in 1 instruction -- the andl might not reserve any. >> special alignment in main(), but assumes that crtso did it. clang also >> doesn't support -mpreferred-stack-boundary, so it is incompatible with >> nonstandard ABI's like the one given by always using >> -mpreferred-stack-boundary=32. > > Apparently upstream never saw the need for this option. I strongly > doubt it is used very often outside FreeBSD... It is most useful for working around gcc's behaviour. Hmm, the kernel and boot blocks uses -mpreferred-stack-boundary=2 on i386 to save space. This must have been turned off for clang, so the versions that did 16-bit alignment must have come close to blowing the kernel stack. In boot blocks, I think there is plenty of stack but alignment wastes code space. I'd like to try -mpreferred-stack-boundary=3 in amd64 kernels, but this is an i386-only option. >> Yes, we need clang/our libraries to handle different alignments and >> not assume that callers do more than the ABI requires and pessimize >> on behalf of the libraries. Outside of libraries, the problem is small >> provided -mpreferred-stack-boundary works, since you can compile >> everything with the same -mpreferred-stack-boundary. > > As far as I can see, with the 4 byte stack alignment that has been the > default, and is now also clang's default, our libraries should handle > any "incoming" stack alignment of >= 4 bytes. I don't think anybody > uses lower stack alignment, except maybe for the special case of boot > loaders, or extremely size-optimized code. -Os could reasonably generate lower stack alignment, but that rarely saves space. -Os generally doesn't give enough control over alignment for space-time tradeoffs. I made some minor changes in FreeBSD's gcc to make it _not_ give misaligned 32-bit variables (?) since -Os should only optimize for space if it doesn't cost much time for small savings in space. But if you only care about space, it would be useful to minimize the alignment of everything. Bruce