This is OK, thanks for catching the pasto!
Only...
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 430d562..b8cb871 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -3974,10 +3974,10 @@ ix86_option_override_internal (bool main_args_p,
if
On Tue, Nov 12, 2013 at 11:05:45AM +0100, Jan Hubicka wrote:
@@ -16576,7 +16576,7 @@ ix86_avx256_split_vector_move_misalign (rtx
op0, rtx op1)
if (MEM_P (op1))
{
- if (TARGET_AVX256_SPLIT_UNALIGNED_LOAD)
+ if (!TARGET_AVX2 TARGET_AVX256_SPLIT_UNALIGNED_LOAD)
On Tue, Nov 12, 2013 at 2:26 AM, Jakub Jelinek ja...@redhat.com wrote:
On Tue, Nov 12, 2013 at 11:05:45AM +0100, Jan Hubicka wrote:
@@ -16576,7 +16576,7 @@ ix86_avx256_split_vector_move_misalign (rtx
op0, rtx op1)
if (MEM_P (op1))
{
- if
On 11/12/2013 05:26 AM, Jakub Jelinek wrote:
On Tue, Nov 12, 2013 at 11:05:45AM +0100, Jan Hubicka wrote:
@@ -16576,7 +16576,7 @@ ix86_avx256_split_vector_move_misalign (rtx
op0, rtx op1)
if (MEM_P (op1))
{
- if (TARGET_AVX256_SPLIT_UNALIGNED_LOAD)
+ if (!TARGET_AVX2
On Tue, Nov 12, 2013 at 10:39:28AM -0500, Vladimir Makarov wrote:
Shall we also disable argument accumulation for cores? It seems we won't
solve the IRA issues, right?
You mean LRA issues here, right? If you are starting to use
no-accumulate-outgoing-args much more often than in the past,
On Tue, Nov 12, 2013 at 10:39:28AM -0500, Vladimir Makarov wrote:
Shall we also disable argument accumulation for cores? It seems we won't
solve the IRA issues, right?
You mean LRA issues here, right? If you are starting to use
no-accumulate-outgoing-args much more often than in the
, 2013 3:57 PM
To: Jan Hubicka
Cc: H.J. Lu; Vladimir Makarov; GCC Patches; Uros Bizjak; Richard Henderson;
Gopalasubramanian, Ganesh
Subject: Re: Honnor ix86_accumulate_outgoing_args again
On Tue, Nov 12, 2013 at 11:05:45AM +0100, Jan Hubicka wrote:
@@ -16576,7 +16576,7
On Thu, Oct 10, 2013 at 08:40:05PM +0200, Jan Hubicka wrote:
--- config/i386/x86-tune.def (revision 203387)
+++ config/i386/x86-tune.def (working copy)
+/* X86_TUNE_AVX256_UNALIGNED_LOAD_OPTIMAL: if true, unaligned loads are
+ split. */
+DEF_TUNE (X86_TUNE_AVX256_UNALIGNED_LOAD_OPTIMAL,
On Mon, Nov 11, 2013 at 4:18 PM, Jakub Jelinek ja...@redhat.com wrote:
On Thu, Oct 10, 2013 at 08:40:05PM +0200, Jan Hubicka wrote:
--- config/i386/x86-tune.def (revision 203387)
+++ config/i386/x86-tune.def (working copy)
+/* X86_TUNE_AVX256_UNALIGNED_LOAD_OPTIMAL: if true, unaligned loads
@gcc.gnu.org
Subject: Re: Honnor ix86_accumulate_outgoing_args again
On 13-10-19 4:30 PM, Jan Hubicka wrote:
Jan,
Does this seem reasonable to you?
Oops, sorry, I missed your email. (I was travelling and I am finishing
a paper now).
Thanks,
Igor
-Original Message
On 10/10/2013 08:40 PM, Jan Hubicka wrote:
+ In 32bit mode enabling argument accumulation results in about 5% code size
+ growth becuase move instructions are less compact than push. In 64bit
+ mode the difference is less drastic but visible.
+
+ FIXME: Unlike earlier implementations,
Jan,
Please see my answers below
-Original Message-
From: Jan Hubicka [mailto:hubi...@ucw.cz]
Sent: Sunday, October 20, 2013 12:30 AM
To: Zamyatin, Igor; gcc-patches@gcc.gnu.org; vmaka...@redhat.com
Cc: 'Jan Hubicka'
Subject: Re: Honnor ix86_accumulate_outgoing_args again
Jan
: RE: Honnor ix86_accumulate_outgoing_args again
Jan,
Now we have following prologue in, say, phi0 routine in equake
0x804aa90 1 push %ebp
0x804aa91 2 mov%esp,%ebp
0x804aa93 3 sub$0x18,%esp
0x804aa96 4 vmovsd 0x80ef7a8,%xmm0
0x804aa9e 5 vmovsd 0x8(%ebp),%xmm1
0x804aaa3 6 vcomisd
, October 14, 2013 8:44 PM
To: Zamyatin, Igor
Cc: Jan Hubicka
Subject: Re: Honnor ix86_accumulate_outgoing_args again
Jan,
I see that you haven't committed this change. Any particular reason for
this?
No, seems I forgot about it.
BTW, after r203171 (http://gcc.gnu.org/ml/gcc
Hi,
this patch makes ACCUMULATE_OUTGOING_ARGS to disable itself when function is
cold. I did some extra testing and to my amusement we now seem to output
more compact unwind info when ACCUMULATE_OUTGOING_ARGS is disabled, so this
seems quite consistent code size win.
We actually can do better
Unfortunately there is 40% regression on mgrid with -flto (and also
noticeable
regression without LTO). First thing I noticed is that we stop omitting
frame
pointer in the hottest function. This is because we see:
Does it happen with both 32-bit and 64-bit?
No, 32bit only.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57018
and because LRA still misses some reload functionality for
elimination. I am a bit embarrassed: I have this thing to do for 4
months and I still did not start to work on it yet. There are too
much things on my plate.
As we are going to
So I thing we ought to honnor accumulate-outgoing-args again and in fact
consider disabling it for generic - it is disabled for core (that may need
re-benchmarking). For all AMD targets it is currently on. I tested disabling
it on buldozer 32bit and it seems mostly SPEC neutral for
On Wed, Oct 2, 2013 at 3:45 PM, Jan Hubicka hubi...@ucw.cz wrote:
So I thing we ought to honnor accumulate-outgoing-args again and in fact
consider disabling it for generic - it is disabled for core (that may need
re-benchmarking). For all AMD targets it is currently on. I tested disabling
it
On 13-10-02 6:45 PM, Jan Hubicka wrote:
So I thing we ought to honnor accumulate-outgoing-args again and in fact
consider disabling it for generic - it is disabled for core (that may need
re-benchmarking). For all AMD targets it is currently on. I tested disabling
it on buldozer 32bit and it
20 matches
Mail list logo
