On 10/10/2014 06:42 PM, Peter Collingbourne wrote:
> A colleague has suggested a perhaps nicer syntax:
>
> __builtin_call_chain(pointer, call) where call must be a call expression
I like this.
Unlike the other suggestions, it doesn't mess with the parsing of the "regular"
part of the function ca
Mike already gave great answers, here are just some of my thoughts on
the specific questions. See embedded below.
On Sat, Oct 11, 2014 at 7:10 AM, Mike Stump wrote:
> [ I'll give the state of the code that I finished with, Bin's answers should
> be similar to mine, but, if he improved things, t
Missed a spot where we need to force noexcept instantiation.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit f8cffba287011ed170e8369372f7867293b19e4a
Author: Jason Merrill
Date: Fri Oct 10 17:26:59 2014 -0400
PR c++/63194
* method.c (defaulted_late_check): Call maybe_instantia
On Fri, Oct 10, 2014 at 6:06 PM, Peter Collingbourne wrote:
> On Fri, Oct 10, 2014 at 5:33 PM, 'Ian Lance Taylor' via gofrontend-dev
> wrote:
>>
>> On Fri, Oct 10, 2014 at 1:42 PM, Richard Henderson wrote:
>> >
>> > This is awful syntax, and therefore contains no documentation.
>> > But we'll ne
On 10/10/2014 04:51 PM, Jeff Law wrote:
On 09/29/14 11:23, Andrew MacLeod wrote:
OK, here's take 2.. I left all the include files except ones which were
duplicated as a result of the flattening. The first one was left, and
any subsequent #Includes of the files were removed. we'll address
"unne
On Fri, Oct 10, 2014 at 1:42 PM, Richard Henderson wrote:
>
> This is awful syntax, and therefore contains no documentation.
> But we'll need to be able to set the static chain on a few calls
> within the Go runtime, so we need to expose this by some means.
>
> It currently looks like
>
>
On Fri, Oct 10, 2014 at 1:42 PM, Richard Henderson wrote:
>
> So instead I thought about how I'd add some support for Go directly
> into libffi. After all, we've got some custom code in libffi for
> Java, why couldn't Go have the same treatment?
>
> The stickler, as far as I could see, is __go_se
On 09/26/2014 11:27 PM, Jan Hubicka wrote:
>> diff --git a/gcc/ipa-icf.c b/gcc/ipa-icf.c
>> new file mode 100644
>> index 000..f3472fe
>> --- /dev/null
>> +++ b/gcc/ipa-icf.c
>> @@ -0,0 +1,2841 @@
>> +/* Interprocedural Identical Code Folding pass
>> + Copyright (C) 2014 Free Software Foundat
On 09/26/2014 09:46 PM, Jan Hubicka wrote:
> Hi,
> this is on ipa-icf-gimple.c
>
> @@ -2827,11 +2829,19 @@ cgraph_node::verify_node (void)
> {
> if (verify_edge_corresponds_to_fndecl (e, decl))
> {
> -
On 09/28/2014 03:20 AM, Jan Hubicka wrote:
>>
>> Hi.
>>
>> Thank you Markus for presenting numbers, it corresponds with I measured. If
>> I see correctly, IPA ICF pass takes about 7 seconds,
>> the rest is distributed in verifier (not interesting for release version of
>> the compiler) and 'phase
On 09/28/2014 04:20 AM, Jan Hubicka wrote:
>>
>> Hi.
>>
>> Thank you Markus for presenting numbers, it corresponds with I measured. If
>> I see correctly, IPA ICF pass takes about 7 seconds,
>> the rest is distributed in verifier (not interesting for release version of
>> the compiler) and 'phase
Hello.
This is a oneline patch that fixed the issue in PR63376. This was a mechanical
error and I will commit it as obivous.
Thank you,
Martin
gcc/ChangeLog:
2014-10-11 Martin Liska
PR/63376
* cgraphunit.c (symbol_table::process_new_functions): Missing call
for call_
[ I’ll give the state of the code that I finished with, Bin’s answers should be
similar to mine, but, if he improved things, they could be better ]
On Oct 10, 2014, at 2:13 PM, Jeff Law wrote:
> So, some questions. Let's assume I've got 3 kinds of insns. A B & C.
>
> I can fuse AB or AC, but
On 09/26/14 09:31, Ilya Tocar wrote:
It's not a question of performance, but of design.
Obviously, but I still fail to see why honoring HARD_REGNO_MODE_OK is
bad design. I suspect that even without avx512 changes not honoring it will
bite us sooner or later.
If we look at maybe_mode_change:
Vladimir Makarov wrote:
> I've tested and benchmarked the sub-pass on x86-64 and ARM. The
> sub-pass permits to generate a smaller code in average on both
> architecture (although improvement no-significant), adds < 0.4%
> additional compilation time in -O2 mode of release GCC (according user
>
On 10/09/14 03:07, Phil Muldoon wrote:
Sorry for taking so long to reply. We've talked, on irc and elsewhere
a little (some at the Cauldron too!). I think the consensus is as
nobody has explicitly mentioned anything, this is OK to go in?
Yes, please go ahead and check it in. You'll be the fir
On Apr 23, 2014, at 3:41 AM, Tom de Vries wrot
> On 22-04-14 17:05, Tom de Vries wrote:
>> I've updated the fuse-caller-save patch series to model non-callee call
>> clobbers
>> in CALL_INSN_FUNCTION_USAGE.
> @item -fuse-caller-save
> Use caller save registers for allocation if those registers a
Ping. Adding Paolo as a build machinery maintainer. Thanks.
Ian
On Mon, Sep 29, 2014 at 5:12 PM, Ian Lance Taylor wrote:
> Similar to a recent patch to libgo, this patch to the libffi configure
> script checks whether the compiler support -Qunused-arguments. If it
> does, it passes -Qunused-a
On 09/30/14 03:22, Bin Cheng wrote:
Hi,
many load/store pairs as my old patch. Then I decided to take one step
forward to introduce a generic instruction fusion infrastructure in GCC,
because in essence, load/store pair is nothing different with other
instruction fusion, all these optimizations
On 09/29/14 11:23, Andrew MacLeod wrote:
OK, here's take 2.. I left all the include files except ones which were
duplicated as a result of the flattening. The first one was left, and
any subsequent #Includes of the files were removed. we'll address
"unneeded" includes separately and all at once
(1) Invent a new "internal.h" rather than polluting the public ffitarget.h
with stuff that ought not be exposed.
(2) Reduce the ifdefs to a minimum. Support the windows and sysv abis at
the same time. After all, it's possible to write functions for any of
these abis with gcc at any t
On Fri, Oct 10, 2014 at 02:26:00PM -0600, Jeff Law wrote:
> On 10/06/14 21:24, tsaund...@mozilla.com wrote:
> >From: Trevor Saunders
> >
> >Hi,
> >
> >This changes almost all of the ggc htab that don't use the if_marked option
> >to
> >be hash_tables. I added a for_user gty attribute so that typ
(1) Invent a new "internal.h" rather than polluting the public ffitarget.h
with stuff that ought not be exposed.
(2) Rewrite is_hfa to not be so horribly computationally expensive. And
more to the point require us to _re_ compute the same stuff in order
to actually do anything with th
---
libffi/src/x86/ffi.c | 88 -
libffi/src/x86/sysv.S | 107 +-
2 files changed, 166 insertions(+), 29 deletions(-)
diff --git a/libffi/src/x86/ffi.c b/libffi/src/x86/ffi.c
index e3f82ef..77abbe3 100644
---
This does drop support for targets whose libffi hasn't been updated,
but if we go this way that should be fairly easy to do.
---
libgo/go/reflect/makefunc.go | 49 ++--
libgo/go/reflect/makefunc_ffi.go | 67 --
libgo/go/reflect/make
---
libffi/src/aarch64/ffi.c | 42 ++---
libffi/src/aarch64/ffitarget.h | 3 ++-
libffi/src/aarch64/sysv.S | 60 +-
3 files changed, 99 insertions(+), 6 deletions(-)
diff --git a/libffi/src/aarch64/ffi.c b/libffi/src/aarc
---
libgo/runtime/proc.c| 20
libgo/runtime/runtime.h | 4
2 files changed, 24 deletions(-)
diff --git a/libgo/runtime/proc.c b/libgo/runtime/proc.c
index 87cd3ed..e52d37c 100644
--- a/libgo/runtime/proc.c
+++ b/libgo/runtime/proc.c
@@ -3370,26 +3370,6 @@ runtime_pr
Still missing changes for darwin, win64, and all 32-bit abis.
Dumps all of the hand-coded unwind info for gas generated, as
I can't be bothered to do the updates by hand again.
---
libffi/src/x86/ffi64.c | 103 ++-
libffi/src/x86/ffitarget.h | 2 +
libffi/src/x86/unix64.S| 31
Doesn't delete the __go_get/set_closure routines yet, as they're
still referenced by the ffi code, to be updated in another patch.
---
libgo/go/reflect/makefunc_386.S | 22 +-
libgo/go/reflect/makefunc_amd64.S | 13 -
libgo/runtime/malloc.goc | 8 ---
A "ffi_go_closure" is intended to be compatible with the
function descriptors used by Go, and ffi_call_go sets up
the static chain parameter for calling a Go function.
The entry points are disabled when a backend has not been
updated, much like we do for "normal" closures.
---
libffi/include/ffi.
As opposed to always being a decl. This is a prerequisite
to allowing the static chain to be loaded for indirect calls.
---
gcc/config/i386/i386.c | 19 +--
gcc/config/moxie/moxie.c | 5 +
gcc/config/xtensa/xtensa.c | 2 +-
gcc/doc/tm.texi| 2 +-
gcc/targe
This is not a standalone patch; it only touches the Go front end.
Further changes are required for the Go runtime.
---
gcc/go/go-gcc.cc | 44 ++--
gcc/go/gofrontend/backend.h | 7 ++-
gcc/go/gofrontend/expressions.cc | 21 --
This is awful syntax, and therefore contains no documentation.
But we'll need to be able to set the static chain on a few calls
within the Go runtime, so we need to expose this by some means.
It currently looks like
function(args...) __builtin_call_chain(pointer)
because that was easy to
And, at the same time, allow indirect calls to have a static chain.
We'll always eliminate the static chain if we can prove it's unused.
---
gcc/calls.c | 14 --
gcc/gimple-fold.c | 21 +
gcc/gimplify.c| 17 -
gcc/tree-cfg.c| 22 +++
Pardon the wide distribution, the obvious hacks, and the failure
to properly split up the largest of the libffi patches.
The background here is my thread from last week[1], and Ian's reply[2],
wherein he rightly points out that not needing to play games with
mmap in order to implement closures for
On 10/06/14 21:24, tsaund...@mozilla.com wrote:
From: Trevor Saunders
Hi,
This changes almost all of the ggc htab that don't use the if_marked option to
be hash_tables. I added a for_user gty attribute so that types could be used
from user marking routines without either using the mangled nam
Jonathan pointed out that lambda closure types were being treated as
non-trivially-copyable for no good reason. It seems that this was
because I missed this case in my patch a while back to distinguish
between deleted and trivial.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit f22332a3
On 10/07/14 15:56, Joern Rennecke wrote:
On 7 October 2014 18:38, Jeff Law wrote:
On 10/06/14 20:57, Joern Rennecke wrote:
On 6 October 2014 19:58, Jeff Law wrote:
What makes word_mode special here? ie, why is special casing for
word_mode
the right thing to do?
The patch does not speci
On 10/08/14 10:04, Richard Sandiford wrote:
Rainer Orth writes:
Hi Richard,
Does this work for you? I tested it on x86_64-linux-gnu but obviously
that's not particularly useful for SEQUENCEs.
the patch is fine, as tested on both sparc-sun-solaris2.11 and (for good
measure) i386-pc-solaris2
On 10/04/14 05:54, Zamyatin, Igor wrote:
Hi!
The following patch does fix random order for new decls generation during
Cilk_spawn generation.
As Jakub suggested in the PR first we deal with vectors, then sort them and
only then perform necessary generation of new decls.
Bootstrapped and regte
On 10/08/14 12:55, Ilya Enkovich wrote:
Hi,
This patch introduces two IPA passes used by Pointer Bounds Checker. One pass
creates clones for instrumentation. The other one transforms unneeded
functions into thunks.
Thanks,
Ilya
--
2014-10-08 Ilya Enkovich
* ipa-chkp.c: New.
On 10/08/14 13:04, Ilya Enkovich wrote:
Hi,
This patch adds intrumentation of calls and returns into instrumentation pass.
Thanks,
Ilya
--
2014-10-08 Ilya Enkovich
* tree-chkp.c (chkp_add_bounds_to_ret_stmt): New.
(chkp_replace_address_check_builtin): New.
(chkp_repl
On 10/08/14 13:27, Ilya Enkovich wrote:
Hi,
This patch adds instrumentation passes into passes list.
Thanks,
Ilya
--
gcc/
2014-10-08 Ilya Enkovich
* passes.def (pass_ipa_chkp_versioning): New.
(pass_early_local_passes): Renamed to pass_build_ssa_passes.
(pass_fixup_
On 10/08/14 13:03, Ilya Enkovich wrote:
Hi,
This patch add function pointers replacement into instrumentation pass.
Thanks,
Ilya
--
2014-10-08 Ilya Enkovich
* tree-chkp.c: Include ipa-chkp.h.
(chkp_replace_function_pointer): New.
(chkp_replace_function_pointers): New
On 10/08/14 13:06, Ilya Enkovich wrote:
Hi,
This patch adds bounds initialization for address taken input arguments.
Thanks,
Ilya
--
2014-10-08 Ilya Enkovich
* tree-chkp.c (chkp_instrument_function): Store bounds for
address taken args.
diff --git a/gcc/tree-chkp.c b/gcc/t
Applying as obvious.
Index: changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-5/changes.html,v
retrieving revision 1.15
diff -r1.15 changes.html
29c29,31
< various misaligned objects.
---
> various misaligned obje
On 10/10/2014 09:52 AM, Richard Henderson wrote:
> I wonder what kind of fallout there would be from changing LO_SUM to
> RTX_BIN_ARITH, which is what it should have been all along.
The answer is "a lot". Mostly throughout simplify-rtx.c, wherein we'd have to
move all sorts of code around to acco
On 10/10/14 11:39, Uros Bizjak wrote:
No objection. In fact, after reading everything it's pretty obvious to me
that a /u MEM must be considered as potentially conflicting with writes that
are implemented as RMW sequences to deal with the lack of byte access
support.
Thanks, I went ahead and
On Fri, Oct 10, 2014 at 7:25 PM, Jeff Law wrote:
> This message revives an old thread [1], where the miscompilation of
> gfortran
> on alpha was found that that resulted in:
>>>
>>>
>>> [...]
>>>
As said in the audit trail of the bugreport I think that the caller
of alpha_se
2014-10-10 21:35 GMT+04:00 Jeff Law :
> On 10/10/14 11:33, Uros Bizjak wrote:
>>
>> On Fri, Oct 10, 2014 at 7:29 PM, Ilya Enkovich
>> wrote:
>>>
>>> 2014-10-10 21:10 GMT+04:00 Uros Bizjak :
On Wed, Oct 1, 2014 at 8:57 PM, Vladimir Makarov
wrote:
> The problem is in code in
On 10/10/14 11:33, Uros Bizjak wrote:
On Fri, Oct 10, 2014 at 7:29 PM, Ilya Enkovich wrote:
2014-10-10 21:10 GMT+04:00 Uros Bizjak :
On Wed, Oct 1, 2014 at 8:57 PM, Vladimir Makarov wrote:
The problem is in code introduced by Bernd in IRA and caller-saves.c in
2012. It is basically an opti
On Fri, Oct 10, 2014 at 7:29 PM, Ilya Enkovich wrote:
> 2014-10-10 21:10 GMT+04:00 Uros Bizjak :
>> On Wed, Oct 1, 2014 at 8:57 PM, Vladimir Makarov wrote:
>>
>>> The problem is in code introduced by Bernd in IRA and caller-saves.c in
>>> 2012. It is basically an optimization for functions retur
2014-10-10 21:10 GMT+04:00 Uros Bizjak :
> On Wed, Oct 1, 2014 at 8:57 PM, Vladimir Makarov wrote:
>
>> The problem is in code introduced by Bernd in IRA and caller-saves.c in
>> 2012. It is basically an optimization for functions returning always the
>> same result as one argument (e.g. memcpy r
On 10/10/14 11:25, Richard Henderson wrote:
On 10/10/2014 10:21 AM, Jeff Law wrote:
On 10/10/14 11:04, Jakub Jelinek wrote:
On Fri, Oct 10, 2014 at 11:00:54AM -0600, Jeff Law wrote:
But it's really a lot more like a
kind of PLUS. If instead we had a LOW to match HIGH it would have been
R
On 10/10/2014 10:21 AM, Jeff Law wrote:
> On 10/10/14 11:04, Jakub Jelinek wrote:
>> On Fri, Oct 10, 2014 at 11:00:54AM -0600, Jeff Law wrote:
>>> But it's really a lot more like a
kind of PLUS. If instead we had a LOW to match HIGH it would have been
>>> Right. In fact, I believe at the h
On 10/10/14 04:06, Uros Bizjak wrote:
On Wed, Oct 8, 2014 at 1:56 PM, Uros Bizjak wrote:
This message revives an old thread [1], where the miscompilation of gfortran
on alpha was found that that resulted in:
[...]
As said in the audit trail of the bugreport I think that the caller
of alpha
On 10/10/14 11:04, Jakub Jelinek wrote:
On Fri, Oct 10, 2014 at 11:00:54AM -0600, Jeff Law wrote:
But it's really a lot more like a
kind of PLUS. If instead we had a LOW to match HIGH it would have been
Right. In fact, I believe at the hardware level it's typically implemented
as addition.
2014-10-10 20:45 GMT+04:00 Jeff Law :
> On 10/09/14 10:54, Uros Bizjak wrote:
>>
>> On Thu, Oct 9, 2014 at 4:07 PM, Ilya Enkovich
>> wrote:
>>>
>>> It appeared I changed a semantics of BNDMK expand when replaced tree
>>> operations with rtl ones.
>>>
>>> Original code:
>>>
>>> + op1 = expand_
On Fri, Oct 10, 2014 at 3:53 AM, Kyrill Tkachov wrote:
> Hi all,
>
>
> Some early revisions of the Cortex-A53 have an erratum (835769) whereby
> it is possible for a 64-bit multiply-accumulate instruction in
> AArch64 state to generate an incorrect result. The details are quite
> complex and hard
On Wed, Oct 1, 2014 at 8:57 PM, Vladimir Makarov wrote:
> The problem is in code introduced by Bernd in IRA and caller-saves.c in
> 2012. It is basically an optimization for functions returning always the
> same result as one argument (e.g. memcpy returning 1st argument).
>
> There are two possi
> The question is what will old assemblers and/or linkers do with that, and
> if there are any that support linker plugins, but not SHF_EXCLUDE.
If it helps answer that question, SHF_EXCLUDE support has been in gold
for 6 years, and in gas for 4.
-cary
On Fri, Oct 10, 2014 at 11:00:54AM -0600, Jeff Law wrote:
> But it's really a lot more like a
> >kind of PLUS. If instead we had a LOW to match HIGH it would have been
> Right. In fact, I believe at the hardware level it's typically implemented
> as addition.
Can be addition or bitwise or, as h
On 10/10/14 10:52, Richard Henderson wrote:
I missed that message. Interesting.
I wonder what kind of fallout there would be from changing LO_SUM to
RTX_BIN_ARITH, which is what it should have been all along.
My guess is that someone looked at HIGH being RTX_CONST_OBJ and thought that
LO_SUM
On Fri, Oct 10, 2014 at 09:51:02AM -0700, Cary Coutant wrote:
> The linker already has a --strip-lto-sections option, and it's on by
> default. I'll approve a patch that modifies gold to recognize
> .gnu.offload_lto.* sections as part of --strip-lto-sections.
>
> Really, though, you should be sett
On 10/10/14 09:50, Ilya Enkovich wrote:
Checks and and intersection removal code was added as a simple pass
catching trivial cases. I'm sure there are optimizations having
common elements with what checker optimizer does. But initially we
didn't want to adopt existing optimizers because GIMPLE
On 10/10/2014 09:39 AM, Jiong Wang wrote:
>> (1) Don't bother modifying single_set; just look for a bare SET.
>> (2) Tighten the set of expressions we're willing to move.
>> (3) Use direct "return false" in the failure case, rather than
>> counting a non-zero number of non-constants, etc.
>>
>
The linker already has a --strip-lto-sections option, and it's on by
default. I'll approve a patch that modifies gold to recognize
.gnu.offload_lto.* sections as part of --strip-lto-sections.
Really, though, you should be setting the SHF_EXCLUDE bit on these
sections. Do that and no special-casing
On 10/10/14 09:02, Vladimir Makarov wrote:
The new LRA rematerialization sub-pass works right before spilling
subpass and tries to rematerialize values of spilled pseudos. To
implement the new sub-pass, some important changes in LRA were done.
First, lra-lives.c updates live info about all re
On 10/09/14 10:54, Uros Bizjak wrote:
On Thu, Oct 9, 2014 at 4:07 PM, Ilya Enkovich wrote:
It appeared I changed a semantics of BNDMK expand when replaced tree operations
with rtl ones.
Original code:
+ op1 = expand_normal (fold_build2 (PLUS_EXPR, TREE_TYPE (arg1),
+
On 10/10/14 16:59, Richard Henderson wrote:
On 10/08/2014 08:31 AM, Jiong Wang wrote:
Ping ~
And as there is NONDEBUG_INSN_P check before move_insn_for_shrink_wrap invoked,
we could avoid creating new wrapper function by invoke single_set_2 directly.
I'm committing the following to fix this.
On Fri, Oct 10, 2014 at 5:47 PM, Ilya Tocar wrote:
>> My strong preference would be:
>> enum machine_mode maskmode = mode;
>> rtx (*gen) (rtx, rtx, rtx, rtx);
>> right below the enum machine_mode mode = GET_MODE (d ? d->op0 : op0);
>> line and then inside of the first switch just do:
>> ...
>
On Fri, Oct 10, 2014 at 12:26:44PM +0200, Jakub Jelinek wrote:
> On Fri, Oct 10, 2014 at 12:04:08PM +0200, Marek Polacek wrote:
> > I couldn't test bootstrap-ubsan, because of error:
> > /home/polacek/x/trunk/prev-x86_64-unknown-linux-gnu/libsanitizer/ubsan/.libs/libubsan.a(ubsan_init.o):
> > .prei
Thanks. I've modified ChangeLog.
2014-10-10 Evgeny Stupachenko
* config/i386/x86-tune.def (X86_TUNE_SSE_PARTIAL_REG_DEPENDENCY):
Remove m_SILVERMONT and m_INTEL from the tune.
On Fri, Oct 10, 2014 at 7:58 PM, H.J. Lu wrote:
> On Fri, Oct 10, 2014 at 8:07 AM, Evgeny Stupachenk
On 10/10/14 02:17, Zhenqiang Chen wrote:
-Original Message-
From: Richard Biener [mailto:richard.guent...@gmail.com]
Sent: Thursday, October 09, 2014 5:21 PM
To: Zhenqiang Chen
Cc: GCC Patches
Subject: Re: [PATCH] Clean up duplicated function seq_cost
On Thu, Oct 9, 2014 at 11:20 AM, R
On 10/10/14 08:19, Ilya Enkovich wrote:
So is the purpose here to expose the checks that would normally be
done in the mem* routines to their caller in the hopes that doing
so will expose redundant checks? Or is there some other reason?
There are few reasons to replace instrumented string func
I've regenerated this file and committed it so I don't get harmless
whitespace changes every time I run autoreconf.
On 10/10/14 08:24, Ilya Enkovich wrote:
On 09 Oct 12:09, Jeff Law wrote:
On 10/08/14 13:16, Ilya Enkovich wrote:
Hi,
This patch introduces structures and manipulation functions used by simple
checker optimizations. Structures are used to hold checks information - type
of check and checked a
On 10/10/14 08:52, Ilya Enkovich wrote:
THanks, Jeff
With this code we remove user builtins calls coming from source code.
E.g.:
p2 = (int *)__bnd_init_ptr_bounds (p1); *p2 = 0;
which means p2 has value of p1 but has default bounds and following
store is unchecked. These calls are important
On 10/10/14 15:18, Christian Bruel wrote:
>
> On 10/09/2014 04:11 PM, Richard Earnshaw wrote:
>> On 09/10/14 12:35, Christian Bruel wrote:
>>> On 10/08/2014 06:56 PM, Ramana Radhakrishnan wrote:
Hi Christian,
>>> << snipped agreed stuf >>
3) about inlining
I dislike inlining diff
On 10/10/14 01:42, Evgeny Stupachenko wrote:
Hi,
The patch enables EBX in RA for x86 32bits PIC mode.
It was discussed here: https://gcc.gnu.org/ml/gcc-patches/2014-09/msg02513.html
Now there is working version with good performance and stability level
- it could be a solid first step of EBX ena
On Fri, 10 Oct 2014, Jakub Jelinek wrote:
> Hi!
>
> As the testcase shows, _Alignof can sometimes return smaller number
> than the minimum alignment. That is because when laying out structures,
> fields with types with TYPE_USER_ALIGN set have also DECL_USER_ALIGN
> set and therefore neither BIG
On Fri, Oct 10, 2014 at 8:07 AM, Evgeny Stupachenko wrote:
> Hi,
>
> We've met several performance issues (up to 15%) on Silvermont caused
> by the PARTIAL_REG_DEPENDENCY tuning.
> Previously discussed here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57954
> Propose removing Silvermont related t
On 10/08/2014 08:31 AM, Jiong Wang wrote:
>
> On 30/09/14 19:36, Jiong Wang wrote:
>> 2014-09-30 17:30 GMT+01:00 Jeff Law :
>>> On 09/30/14 08:37, Jiong Wang wrote:
On 30/09/14 05:21, Jeff Law wrote:
> I do agree with Richard that it would be useful to see the insns that
> a
On Fri, Oct 10, 2014 at 07:47:19PM +0400, Ilya Tocar wrote:
> Updated patch below.
You haven't posted ChangeLog entry this time, so using the last one:
* config/i386/i386.c
2014-10-09 21:41 GMT+04:00 Jeff Law :
> On 10/08/14 13:22, Ilya Enkovich wrote:
>>
>> Hi,
>>
>> This patch adds removal of redundant (covered by other) checks into
>> checker optimization.
>>
>> Thanks,
>> Ilya
>> --
>> 2014-10-08 Ilya Enkovich
>>
>> * tree-chkp.c (chkp_compare_checks):
On 10/09/2014 04:11 PM, Richard Earnshaw wrote:
> On 09/10/14 12:35, Christian Bruel wrote:
>> On 10/08/2014 06:56 PM, Ramana Radhakrishnan wrote:
>>> Hi Christian,
>> << snipped agreed stuf >>
>>> 3) about inlining
>>>I dislike inlining different modes, From a conceptual use, a user
>>> might
On 09 Oct 20:51, Jakub Jelinek wrote:
> On Thu, Oct 09, 2014 at 04:15:23PM +0400, Ilya Tocar wrote:
> > --- a/gcc/config/i386/i386.c
> > +++ b/gcc/config/i386/i386.c
> > @@ -21358,32 +21358,169 @@ ix86_expand_int_vcond (rtx operands[])
> >return true;
> > }
> >
> > -ix86_expand_vec_perm_vper
On 03/10/14 15:49 +0100, Jonathan Wakely wrote:
On 03/10/14 16:25 +0200, Marc Glisse wrote:
On Fri, 3 Oct 2014, Jonathan Wakely wrote:
This is the patch I intend to commit to make std::list::size() O(1) as
required by C++11.
This is an ABI change, so std::list will get tagged with
abi_tag("cx
Hi,
The patch increase PARAM_MAX_COMPLETELY_PEELED_INSNS for CPUs with
high branch cost.
Bootstrap and make check are in progress.
The patch boosts (up to 2,5 times improve) several benchmarks compiled
with "-Ofast" on Silvermont
Spec2000:
+5% gain on 173.applu
+1% gain on 255.vortex
Is it ok for
On 10/10/14 15:22, Kyrill Tkachov wrote:
>
> On 10/10/14 15:18, Richard Earnshaw wrote:
>> On 10/10/14 11:53, Kyrill Tkachov wrote:
>>> Hi all,
>>>
>>>
>>> Some early revisions of the Cortex-A53 have an erratum (835769) whereby
>>> it is possible for a 64-bit multiply-accumulate instruction in
>>>
On 2014-10-10 3:42 AM, Evgeny Stupachenko wrote:
Hi,
The patch enables EBX in RA for x86 32bits PIC mode.
It was discussed here: https://gcc.gnu.org/ml/gcc-patches/2014-09/msg02513.html
Now there is working version with good performance and stability level
- it could be a solid first step of EBX
This patch is dependant on "[AArch64] [BE] [1/2] Make large opaque integer
modes endianness-safe.”
It fixes up movoi/ci/xi for Big Endian, so that we end up with the lsb of
a big-endian integer to be in the low byte of the highest-numbered
register.
movoi uses stp/ldp
movxi needs a split version
On Fri, Oct 10, 2014 at 5:07 PM, Evgeny Stupachenko wrote:
> We've met several performance issues (up to 15%) on Silvermont caused
> by the PARTIAL_REG_DEPENDENCY tuning.
> Previously discussed here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57954
> Propose removing Silvermont related tune fro
Hi,
We've met several performance issues (up to 15%) on Silvermont caused
by the PARTIAL_REG_DEPENDENCY tuning.
Previously discussed here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57954
Propose removing Silvermont related tune from PARTIAL_REG_DEPENDENCY.
The patch passed bootstrap, make chec
On 2014-10-08 10:21 PM, Jeff Law wrote:
On 10/01/14 17:27, David Malcolm wrote:
FWIW, presumably "insn" here also can now be an rtx_insn *?
(I'd like to eventually strengthen the params to the note-handling
functions, so fixing this up now would help with that).
Here's the updated patch to in
Here is a new rematerialization sub-pass of LRA.
This summer, I tried to implement a separate register pressure
release pass based on rematerialization described in Simpson's PhD.
Although this approach is very attractive as implementation of a
separate pass is simpler, it did not work in GCC
Hi,
I forgot to mention that this patch needs was tested in combination with another
patch by Alan Hayward (coming soon) and observed the following:
x86_64: No regressions.
aarch64: No regressions.
aarch64_be: Lots of vector tests now fixed. No new regressions.
Regards,
David.
-Original Me
On Fri, Oct 10, 2014 at 04:50:47PM +0200, Christophe Lyon wrote:
> On 10 October 2014 16:19, Jakub Jelinek wrote:
> > On Fri, Oct 10, 2014 at 04:09:39PM +0200, Christophe Lyon wrote:
> >> my.exp contains the following construct which is often used in the
> >> testsuite:
> >> ==
> >> forea
On 09 Oct 15:03, Jeff Law wrote:
> On 10/08/14 13:08, Ilya Enkovich wrote:
> >Hi,
> >
> >This patch adds removal of user calls to chkp builtins which become useless
> >after instrumentation.
> >
> >Thanks,
> >Ilya
> >--
> >2014-10-08 Ilya Enkovich
> >
> > * tree-chkp.c (chkp_remove_useless_
On 10 October 2014 16:19, Jakub Jelinek wrote:
> On Fri, Oct 10, 2014 at 04:09:39PM +0200, Christophe Lyon wrote:
>> my.exp contains the following construct which is often used in the testsuite:
>> ==
>> foreach src [lsort [glob -nocomplain $srcdir/$subdir/*.c]] {
>> # If we're only te
1 - 100 of 153 matches
Mail list logo
