--- Comment #50 from janis at gcc dot gnu dot org 2009-03-13 17:05 ---
Subject: Bug 39137
Author: janis
Date: Fri Mar 13 17:05:08 2009
New Revision: 144841
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144841
Log:
2009-03-13 Jack Howarth howa...@bromo.med.uc.edu
PR
--- Comment #47 from Joey dot ye at intel dot com 2009-03-12 06:51 ---
(In reply to comment #46)
Created an attachment (id=17444)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17444action=view) [edit]
gcc.target/i386/stackalign/longlong-2.c for -mnostackalign on darwin10
--- Comment #48 from rguenth at gcc dot gnu dot org 2009-03-12 09:43
---
If it ignores -mpreferred-stack-boundary it shouldn't end up setting
ix86_preferred_stack_boundary to the ignored value.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39137
--- Comment #49 from hjl dot tools at gmail dot com 2009-03-12 13:30
---
(In reply to comment #48)
If it ignores -mpreferred-stack-boundary it shouldn't end up setting
ix86_preferred_stack_boundary to the ignored value.
i386/darwin.h has
/* On Darwin, the stack is 128-bit aligned
--- Comment #36 from rguenth at gcc dot gnu dot org 2009-03-11 14:47
---
In reply to comment #34, we should be able to fixup alignment in
get_decl_align_unit if DECL_USER_ALIGN is set (or change the prototype
for LOCAL_ALIGNMENT to take a decl and/or a type).
I wonder why we have both
--- Comment #37 from jakub at gcc dot gnu dot org 2009-03-11 16:26 ---
Created an attachment (id=17440)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17440action=view)
gcc44-pr39137.patch
Patch I'm going to bootstrap/regtest now. I've re-added the TYPE_USER_ALIGN
check, because
--- Comment #38 from jakub at gcc dot gnu dot org 2009-03-11 17:14 ---
Created an attachment (id=17442)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17442action=view)
gcc44-pr39137-2.patch
Alternative patch which does stack realignment in f[2345] rather than just in
f[345].
--
--- Comment #39 from hjl dot tools at gmail dot com 2009-03-11 17:17
---
(In reply to comment #38)
Created an attachment (id=17442)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17442action=view) [edit]
gcc44-pr39137-2.patch
Alternative patch which does stack realignment in
--- Comment #40 from rguenth at gcc dot gnu dot org 2009-03-11 20:04
---
Both patches look ok to me. For 4.5 we might want to consider merging
some of the target hooks though.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39137
--- Comment #41 from jakub at gcc dot gnu dot org 2009-03-11 21:12 ---
Subject: Bug 39137
Author: jakub
Date: Wed Mar 11 21:12:33 2009
New Revision: 144792
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144792
Log:
PR target/39137
* cfgexpand.c
--- Comment #42 from jakub at gcc dot gnu dot org 2009-03-11 21:23 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #43 from howarth at nitro dot med dot uc dot edu 2009-03-12
00:41 ---
On darwin10, I am seeing...
Executing on host:
/sw/src/fink.build/gcc44-4.3.999-20090311/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc44-4.3.999-20090311/darwin_objdir/gcc/
--- Comment #44 from hjl dot tools at gmail dot com 2009-03-12 00:44
---
Those tests should be skipped on MacOS since it ignores
-mpreferred-stack-boundary=2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39137
--- Comment #45 from howarth at nitro dot med dot uc dot edu 2009-03-12
00:45 ---
Created an attachment (id=17443)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17443action=view)
gcc.target/i386/stackalign/longlong-2.c for -mstackalign on darwin10
--- Comment #46 from howarth at nitro dot med dot uc dot edu 2009-03-12
00:46 ---
Created an attachment (id=17444)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17444action=view)
gcc.target/i386/stackalign/longlong-2.c for -mnostackalign on darwin10
--- Comment #32 from jakub at gcc dot gnu dot org 2009-03-03 10:36 ---
I don't see the reason for optimize_function_for_size_p (cfun), care to back
up with benchmarks that forcing dynamic realignment for long long variables
with -mpreferred-stack-boundary=2 improves performance rather
--- Comment #33 from hjl dot tools at gmail dot com 2009-03-03 14:48
---
(In reply to comment #32)
I don't see the reason for optimize_function_for_size_p (cfun), care to
back
up with benchmarks that forcing dynamic realignment for long long variables
with
--- Comment #34 from jakub at gcc dot gnu dot org 2009-03-03 16:01 ---
Yeah, unsigned long long l __attribute__ ((aligned(8))); won't be 64-bit
aligned with -m32 -mpreferred-stack-boundary=2, but I think that's not a big
deal and isn't a regression from 4.3 and earlier anyway.
--
--- Comment #35 from Joey dot ye at intel dot com 2009-03-04 01:41 ---
(In reply to comment #32)
I don't see the reason for optimize_function_for_size_p (cfun), care to
back
up with benchmarks that forcing dynamic realignment for long long variables
with
--- Comment #29 from hubicka at gcc dot gnu dot org 2009-02-22 18:46
---
I mean aligned(64).
I guess something like this then?
Index: config/i386/i386.c
===
--- config/i386/i386.c (revision 144373)
+++ config/i386/i386.c
--- Comment #30 from hjl dot tools at gmail dot com 2009-02-22 19:28
---
(In reply to comment #29)
I mean aligned(64).
I guess something like this then?
Index: config/i386/i386.c
===
--- config/i386/i386.c (revision
--- Comment #31 from Joey dot ye at intel dot com 2009-02-23 03:15 ---
How about this patch?
1. Only reduce DI mode when -Os
2. Ignore TYPE_USER_ALIGN, so that stack realign happens for case in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39137#c28, which IMHO is
acceptable.
Index:
--- Comment #26 from hubicka at gcc dot gnu dot org 2009-02-21 13:00
---
I had somehting along this lines in mind:
Index: config/i386/i386.c
===
*** config/i386/i386.c (revision 144352)
--- config/i386/i386.c (working
--- Comment #27 from rguenth at gcc dot gnu dot org 2009-02-21 13:05
---
That patch looks reasonable. Care to bootstrap/test it to settle this last P1?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39137
--- Comment #28 from hjl dot tools at gmail dot com 2009-02-21 15:38
---
(In reply to comment #26)
I had somehting along this lines in mind:
Index: config/i386/i386.c
===
*** config/i386/i386.c (revision 144352)
---
--- Comment #20 from Joey dot ye at intel dot com 2009-02-17 09:18 ---
(In reply to comment #19)
Just for the record, here is an unsuccessful attempt to avoid stack
realignment
just because of DImode for -m32 or because of DFmode at -m32 -Os. This patch
unfortunately caused a
--- Comment #21 from jakub at gcc dot gnu dot org 2009-02-17 09:29 ---
Unless you consider that option being -mpreferred-stack-boundary=2. By default
stack boundary is bigger and so DImode is aligned naturally, it is only when
you want very compat code that you use this option.
--
--- Comment #22 from hjl dot tools at gmail dot com 2009-02-17 14:52
---
-mpreferred-stack-boundary=2 can also be used to generate psABI
conforming code. I think we need a new option to align DImode
to 4 byte on stack if we want to change DImode alignment on stack.
--
--- Comment #23 from jakub at gcc dot gnu dot org 2009-02-17 15:25 ---
I guess I can live with a switch, the kernel folks will just need to add it.
Now, should that switch be about disabling all dynamic stack realignments, or
do that for DImode only, or decrease DImode alignment when on
--- Comment #24 from hjl dot tools at gmail dot com 2009-02-17 15:40
---
(In reply to comment #23)
I guess I can live with a switch, the kernel folks will just need to add it.
Now, should that switch be about disabling all dynamic stack realignments, or
do that for DImode only, or
--- Comment #25 from hjl dot tools at gmail dot com 2009-02-17 17:29
---
Created an attachment (id=17311)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17311action=view)
A patch to add a new -malign-long-long= option
Here is a patch to add a new option, -malign-long-long=.
--
--- Comment #19 from jakub at gcc dot gnu dot org 2009-02-13 19:15 ---
Created an attachment (id=17296)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17296action=view)
Unsuccessful attempt to avoid stack realignment for DImode and for DFmode at
-Os
Just for the record, here is an
--- Comment #14 from jakub at gcc dot gnu dot org 2009-02-12 08:03 ---
Won't this break Ada again (with -malign-double=2)? I think we should reject
-malign-double= for -m64.
Alternatively, what about making MAX_STACK_ALIGNMENT a parameter instead, so
kernel could use
--- Comment #15 from hubicka at gcc dot gnu dot org 2009-02-12 16:47
---
The DFmode and DImodes are different. Aligning DFmode on stack is very
performance critical, while DImodes on 32bit machine can quite safely be
misaligned (if we ignore their possible use in MMX intrincisc).
I
--- Comment #16 from hjl dot tools at gmail dot com 2009-02-12 17:01
---
(In reply to comment #15)
The DFmode and DImodes are different. Aligning DFmode on stack is very
performance critical, while DImodes on 32bit machine can quite safely be
misaligned (if we ignore their possible
--- Comment #17 from ubizjak at gmail dot com 2009-02-12 18:23 ---
(In reply to comment #15)
The DFmode and DImodes are different. Aligning DFmode on stack is very
performance critical, while DImodes on 32bit machine can quite safely be
misaligned (if we ignore their possible use in
--- Comment #18 from jakub at gcc dot gnu dot org 2009-02-12 21:17 ---
In that case people probably wouldn't use -mpreferred-stack-boundary=2
though...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39137
--- Comment #11 from ubizjak at gmail dot com 2009-02-11 08:42 ---
(In reply to comment #9)
Created an attachment (id=17279)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17279action=view) [edit]
A patch to add a new -malign-double= option
HJ, there were lots of problems with
--- Comment #12 from hjl dot tools at gmail dot com 2009-02-11 14:39
---
(In reply to comment #11)
(In reply to comment #9)
Created an attachment (id=17279)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17279action=view) [edit]
A patch to add a new -malign-double= option
--- Comment #13 from pinskia at gcc dot gnu dot org 2009-02-11 22:11
---
Is there a reason why this is a P1? I don't see why this should be a P1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39137
--- Comment #5 from hjl dot tools at gmail dot com 2009-02-10 20:32 ---
Created an attachment (id=17277)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17277action=view)
A patch
Does this patch look OK? If yes, I will submit it with a couple of
testcases.
--
--- Comment #6 from jakub at gcc dot gnu dot org 2009-02-10 20:48 ---
This would mean -Os vs. -O2 gives different __alignof__(long long) values, I
think that's a bad idea. I think a new option to disable dynamic realignment
or at least do that if estimated stack size is = 64 bits would
--- Comment #7 from hjl dot tools at gmail dot com 2009-02-10 21:02 ---
(In reply to comment #6)
This would mean -Os vs. -O2 gives different __alignof__(long long) values, I
think that's a bad idea. I think a new option to disable dynamic realignment
or at least do that if estimated
--- Comment #8 from hjl dot tools at gmail dot com 2009-02-10 21:15 ---
(In reply to comment #6)
This would mean -Os vs. -O2 gives different __alignof__(long long) values, I
__alignof__(type) isn't that useful. The alignment of double
changes depending on
1. If it is on stack.
2. If
--- Comment #9 from hjl dot tools at gmail dot com 2009-02-10 22:29 ---
Created an attachment (id=17279)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17279action=view)
A patch to add a new -malign-double= option
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39137
--- Comment #10 from Joey dot ye at intel dot com 2009-02-11 01:03 ---
(In reply to comment #9)
Created an attachment (id=17279)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17279action=view) [edit]
A patch to add a new -malign-double= option
This patch looks OK to me.
--
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39137
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-02-09 14:39 ---
Confirmed. I think with -Os or even more with -mpreferred-stack-boundary
dynamic stack alignment should _not_ be used.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from hjl dot tools at gmail dot com 2009-02-09 14:57 ---
(In reply to comment #1)
Confirmed. I think with -Os or even more with -mpreferred-stack-boundary
dynamic stack alignment should _not_ be used.
That will cause core dump on programs with __m128/__m256. We have
--- Comment #3 from jakub at gcc dot gnu dot org 2009-02-09 15:06 ---
How can #1 cause a problem with -ftree-vectorize (especially when it hasn't
been problem in 4.3 and earlier)? We'd do realignment for V[1248]* modes, just
not for DImode/DFmode...
--
--- Comment #4 from hjl dot tools at gmail dot com 2009-02-09 15:21 ---
(In reply to comment #3)
How can #1 cause a problem with -ftree-vectorize (especially when it hasn't
I don't believe -mpreferred-stack-boundary=2 -ftree-vectorize works
well in gcc 4.3.
been problem in 4.3 and
51 matches
Mail list logo
