Re: CVS commit: src/external/gpl3/gcc/dist/gcc/config/i386
On Mon, Dec 31, 2012 at 10:08:18AM +, David Laight wrote: On Mon, Dec 31, 2012 at 03:00:42AM +0100, Joerg Sonnenberger wrote: On Sun, Dec 30, 2012 at 08:16:59PM +, David Laight wrote: Module Name: src Committed By: dsl Date: Sun Dec 30 20:16:59 UTC 2012 Modified Files: src/external/gpl3/gcc/dist/gcc/config/i386: i386.c Log Message: No need to check both TARGET_64BIT and ix86_preferred_stack_boundary = 64, if the former is true the latter is also true. At least in terms of documentation, this is a regression. TARGET_64BIT implies the presence of SSE support and that's somewhat independent of the separate preferred stack boundary Eh? TARGET_64BIT forces ix86_preferred_stack_boundary = 64. The fact that it also implies SSE support is relevant. Only as default value, not if explicitly overriden? Joerg
Re: CVS commit: src/external/gpl3/gcc/dist/gcc/config/i386
On Thu, Jan 03, 2013 at 03:46:08PM +0100, Joerg Sonnenberger wrote: At least in terms of documentation, this is a regression. TARGET_64BIT implies the presence of SSE support and that's somewhat independent of the separate preferred stack boundary Eh? TARGET_64BIT forces ix86_preferred_stack_boundary = 64. The fact that it also implies SSE support is relevant. Only as default value, not if explicitly overriden? It won't let you override to a lower value. David -- David Laight: da...@l8s.co.uk
Re: CVS commit: src/external/gpl3/gcc/dist/gcc/config/i386
On Mon, Dec 31, 2012 at 03:00:42AM +0100, Joerg Sonnenberger wrote: On Sun, Dec 30, 2012 at 08:16:59PM +, David Laight wrote: Module Name:src Committed By: dsl Date: Sun Dec 30 20:16:59 UTC 2012 Modified Files: src/external/gpl3/gcc/dist/gcc/config/i386: i386.c Log Message: No need to check both TARGET_64BIT and ix86_preferred_stack_boundary = 64, if the former is true the latter is also true. At least in terms of documentation, this is a regression. TARGET_64BIT implies the presence of SSE support and that's somewhat independent of the separate preferred stack boundary Eh? TARGET_64BIT forces ix86_preferred_stack_boundary = 64. The fact that it also implies SSE support is relevant. David -- David Laight: da...@l8s.co.uk
re: CVS commit: src/external/gpl3/gcc/dist/gcc/config/i386
Module Name: src Committed By: dsl Date: Sun Dec 30 20:16:59 UTC 2012 Modified Files: src/external/gpl3/gcc/dist/gcc/config/i386: i386.c Log Message: No need to check both TARGET_64BIT and ix86_preferred_stack_boundary = 64, if the former is true the latter is also true. can this not be overriden with cli options? the old test seems safer.
Re: CVS commit: src/external/gpl3/gcc/dist/gcc/config/i386
On Tue, Jan 01, 2013 at 02:06:31AM +1100, matthew green wrote: Module Name:src Committed By: dsl Date: Sun Dec 30 20:16:59 UTC 2012 Modified Files: src/external/gpl3/gcc/dist/gcc/config/i386: i386.c Log Message: No need to check both TARGET_64BIT and ix86_preferred_stack_boundary = 64, if the former is true the latter is also true. can this not be overriden with cli options? the old test seems safer. No - for amd64 the ix86_preferred_stack_boundary is always = 64. David -- David Laight: da...@l8s.co.uk
Re: CVS commit: src/external/gpl3/gcc/dist/gcc/config/i386
On Sun, Dec 30, 2012 at 08:16:59PM +, David Laight wrote: Module Name: src Committed By: dsl Date: Sun Dec 30 20:16:59 UTC 2012 Modified Files: src/external/gpl3/gcc/dist/gcc/config/i386: i386.c Log Message: No need to check both TARGET_64BIT and ix86_preferred_stack_boundary = 64, if the former is true the latter is also true. At least in terms of documentation, this is a regression. TARGET_64BIT implies the presence of SSE support and that's somewhat independent of the separate preferred stack boundary Joerg
Re: CVS commit: src/external/gpl3/gcc/dist/gcc/config/i386
On Sat, Oct 06, 2012 at 02:10:46PM +, Joerg Sonnenberger wrote: Module Name: src Committed By: joerg Date: Sat Oct 6 14:10:46 UTC 2012 Modified Files: src/external/gpl3/gcc/dist/gcc/config/i386: i386.h Log Message: PR 46978: ICE on spilling MMX registers GCC/i386 has code to lower the required alignment for long long to 32bit as the CPU doesn't need more. It is also using the same mode for setting up the MMX registers and in turn, the stack slots reserved for spilling require 32bit alignment. The actual vector types used keep the original 64bit alignment, so when the compiler wants to spill a MMX register, it hits an assertion. Fix this by using the vector type as raw type for MMX registers. Doesn't that enforce a 64bit alignment when it isn't needed? Or have I misread the commit message? Misaligned transfers for stack slots for MMX are actually fine. Only the 128bit (and larger) accesses have to be aligned. The performance penalty of misaligned 64bit transfers really is best avoided by maintaining the stack alignment - and assuming it won't get misaligned. I suspect that the 'sub %sp,n' use to allocate a stack frame has hardware optimisations that are absent from the 'and %sp,~7' needed to realign it. David -- David Laight: da...@l8s.co.uk
Re: CVS commit: src/external/gpl3/gcc/dist/gcc/config/i386
On Fri, Sep 14, 2012 at 01:00:01PM +, Joerg Sonnenberger wrote: Module Name: src Committed By: joerg Date: Fri Sep 14 13:00:01 UTC 2012 Modified Files: src/external/gpl3/gcc/dist/gcc/config/i386: i386.c netbsd-elf.h netbsd64.h Log Message: Fix GCC to correctly implement the i386 psABI on NetBSD. This consists of two parts: - for NetBSD/i386 and NetBSD/AMD64 with -m32, use a default stack alignment of 23bit as specified by the ABI - ensure that double and long long variables on the stack are by default only aligned to 32bit, if there is nothing else in the function needing a larger stack alignment The combination ensures that SSE variables on the stack trigger the realignment logic, but just using double or long long doesn't. To generate a diff of this commit: cvs rdiff -u -r1.1.1.1 -r1.2 \ src/external/gpl3/gcc/dist/gcc/config/i386/i386.c \ src/external/gpl3/gcc/dist/gcc/config/i386/netbsd64.h cvs rdiff -u -r1.2 -r1.3 \ src/external/gpl3/gcc/dist/gcc/config/i386/netbsd-elf.h Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files. I'm still to be convinced that the patches are correct. David -- David Laight: da...@l8s.co.uk
