Hi!
This patch optimizes using peephole2 __sync_fetch_and_add (x, -N) == N
and __sync_add_and_fetch (x, N) == 0 by just doing lock {add,sub,inc,dec}
and testing flags, instead of lock xadd plus comparison.
The sync_old_add predicate change makes it possible to optimize
__sync_add_and_fetch with co
On 2011/5/13 04:26 PM, Richard Sandiford wrote:
> Richard Sandiford writes:
>> Chung-Lin Tang writes:
>>> My fix here simply adds 'reload_completed' as an additional condition
>>> for EPILOGUE_USES to return true for LR_REGNUM. I think this should be
>>> valid, as correct LR save/restoring is han
Hi Zdenek,
I have a patch set for for PR45098.
01_object-size-target.patch
02_pr45098-rtx-cost-set.patch
03_pr45098-computation-cost.patch
04_pr45098-iv-init-cost.patch
05_pr45098-bound-cost.patch
06_pr45098-bound-cost.test.patch
07_pr45098-nowrap-limits-iterations.patch
08_pr45098-nowrap-limits-
On 05/17/2011 09:10 AM, Tom de Vries wrote:
> Hi Zdenek,
>
> I have a patch set for for PR45098.
>
> 01_object-size-target.patch
> 02_pr45098-rtx-cost-set.patch
> 03_pr45098-computation-cost.patch
> 04_pr45098-iv-init-cost.patch
> 05_pr45098-bound-cost.patch
> 06_pr45098-bound-cost.test.patch
> 0
On Mon, May 16, 2011 at 02:13:22PM +0200, Jakub Jelinek wrote:
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Actually, I've missed one regression in libjava testing on x86_64-linux,
FAIL: pr26390 -O3 compilation from source
The problem is when cselib_subst_to_values substs
On 05/17/2011 09:10 AM, Tom de Vries wrote:
> Hi Zdenek,
>
> I have a patch set for for PR45098.
>
> 01_object-size-target.patch
> 02_pr45098-rtx-cost-set.patch
> 03_pr45098-computation-cost.patch
> 04_pr45098-iv-init-cost.patch
> 05_pr45098-bound-cost.patch
> 06_pr45098-bound-cost.test.patch
> 0
On 05/17/2011 09:10 AM, Tom de Vries wrote:
> Hi Zdenek,
>
> I have a patch set for for PR45098.
>
> 01_object-size-target.patch
> 02_pr45098-rtx-cost-set.patch
> 03_pr45098-computation-cost.patch
> 04_pr45098-iv-init-cost.patch
> 05_pr45098-bound-cost.patch
> 06_pr45098-bound-cost.test.patch
> 0
On 05/17/2011 09:10 AM, Tom de Vries wrote:
> Hi Zdenek,
>
> I have a patch set for for PR45098.
>
> 01_object-size-target.patch
> 02_pr45098-rtx-cost-set.patch
> 03_pr45098-computation-cost.patch
> 04_pr45098-iv-init-cost.patch
> 05_pr45098-bound-cost.patch
> 06_pr45098-bound-cost.test.patch
> 0
On 05/17/2011 09:10 AM, Tom de Vries wrote:
> Hi Zdenek,
>
> I have a patch set for for PR45098.
>
> 01_object-size-target.patch
> 02_pr45098-rtx-cost-set.patch
> 03_pr45098-computation-cost.patch
> 04_pr45098-iv-init-cost.patch
> 05_pr45098-bound-cost.patch
> 06_pr45098-bound-cost.test.patch
> 0
On 05/17/2011 09:10 AM, Tom de Vries wrote:
> Hi Zdenek,
>
> I have a patch set for for PR45098.
>
> 01_object-size-target.patch
> 02_pr45098-rtx-cost-set.patch
> 03_pr45098-computation-cost.patch
> 04_pr45098-iv-init-cost.patch
> 05_pr45098-bound-cost.patch
> 06_pr45098-bound-cost.test.patch
> 0
On 05/17/2011 09:10 AM, Tom de Vries wrote:
> Hi Zdenek,
>
> I have a patch set for for PR45098.
>
> 01_object-size-target.patch
> 02_pr45098-rtx-cost-set.patch
> 03_pr45098-computation-cost.patch
> 04_pr45098-iv-init-cost.patch
> 05_pr45098-bound-cost.patch
> 06_pr45098-bound-cost.test.patch
> 0
On 05/17/2011 09:10 AM, Tom de Vries wrote:
> Hi Zdenek,
>
> I have a patch set for for PR45098.
>
> 01_object-size-target.patch
> 02_pr45098-rtx-cost-set.patch
> 03_pr45098-computation-cost.patch
> 04_pr45098-iv-init-cost.patch
> 05_pr45098-bound-cost.patch
> 06_pr45098-bound-cost.test.patch
> 0
On 05/17/2011 09:10 AM, Tom de Vries wrote:
> Hi Zdenek,
>
> I have a patch set for for PR45098.
>
> 01_object-size-target.patch
> 02_pr45098-rtx-cost-set.patch
> 03_pr45098-computation-cost.patch
> 04_pr45098-iv-init-cost.patch
> 05_pr45098-bound-cost.patch
> 06_pr45098-bound-cost.test.patch
> 0
On 05/17/2011 09:10 AM, Tom de Vries wrote:
> Hi Zdenek,
>
> I have a patch set for for PR45098.
>
> 01_object-size-target.patch
> 02_pr45098-rtx-cost-set.patch
> 03_pr45098-computation-cost.patch
> 04_pr45098-iv-init-cost.patch
> 05_pr45098-bound-cost.patch
> 06_pr45098-bound-cost.test.patch
> 0
On Tue, May 17, 2011 at 9:02 AM, Jakub Jelinek wrote:
> Hi!
>
> This patch optimizes using peephole2 __sync_fetch_and_add (x, -N) == N
> and __sync_add_and_fetch (x, N) == 0 by just doing lock {add,sub,inc,dec}
> and testing flags, instead of lock xadd plus comparison.
> The sync_old_add predicate
On Mon, May 16, 2011 at 10:27:44PM -0700, Ian Lance Taylor wrote:
> On Mon, May 16, 2011 at 6:42 AM, Richard Guenther
> wrote:
> >>>
> >>> httpd being in the top-10 always, fiddling with bugzilla URLs?
> >>> (Note, I don't have access to gcc.gnu.org, I'm relaying info from multiple
> >>> instances
Hi Guys,
I am applying the patch below to add a peephole optimization to the RX
backend. It was suggested by Kazuhio Inaoka at Renesas Japan, and
adapted by me to use peephole2 system. It finds a register move
followed by a comparison of the moved register against zero and
replaces the
On Mon, 16 May 2011, Jan Hubicka wrote:
> >
> > I've seen us merge different named structs which happen to reside
> > on the same variant list. That's bogus, not only because we are
> > adjusting TYPE_MAIN_VARIANT during incremental type-merging and
> > fixup, so computing a persistent hash by l
Hi Guys,
I am applying the patch below to add a couple of peephole
optimizations to the RX backend. It seems that GCC does not cope very
well with the RX's ability to perform either sign-extending loads or
zero-extending loads and so sometimes it can generate an extending
load followed
Hi Guys,
I am applying the patch below to fix a minor discrepancy in the rx.md
file. Several patterns can only use restricted memory addresses.
They have the correct Q constraint, but they were using the more
permissive memory_operand predicate. The patch fixes these patterns
by replac
Hi Guys,
I am applying the patch below to fix a bug with the
rx_memory_move_cost function. The problem was that the costs are
meant to be relative to the cost of moving a value between registers,
but the existing definition was making stores cheaper than moves, and
loads the same cost a
On Mon, May 16, 2011 at 7:30 PM, William J. Schmidt
wrote:
> Richi, thank you for the detailed review!
>
> I'll plan to move the power-series expansion into the existing IL walk
> during pass_cse_sincos. As part of this, I'll move
> tree_expand_builtin_powi and its subfunctions from builtins.c in
This avoids the odd cases where gimple_register_canonical_type could
end up running in cycles. I was able to reproduce this issue
with an intermediate tree and LTO bootstrap. While the following
patch is not the "real" fix (that one runs into a known cache-preloading
issue again ...) it certainl
On Mon, 16 May 2011, H.J. Lu wrote:
> On Mon, May 16, 2011 at 7:17 AM, Richard Guenther wrote:
> >
> > The following patch improves hashing types by re-instantiating the
> > patch that makes us visit aggregate target types of pointers and
> > function return and argument types. This halves the c
> Right, -mflat option should only be for 32-bit SPARC target.
OK, let's keep it that way for now.
Another question: why does the model hijack %i7 to use it as frame pointer,
instead of just using %fp? AFAICS both are kept as fixed registers by the
code so the model seems to be wasting 1 regis
Hi,
On Mon, 16 May 2011, Ian Lance Taylor wrote:
> >>> httpd being in the top-10 always, fiddling with bugzilla URLs?
> >>> (Note, I don't have access to gcc.gnu.org, I'm relaying info from
> >>> multiple instances of discussion on #gcc and richi poking on it;
> >>> that said, it still might n
> On Mon, 16 May 2011, Jan Hubicka wrote:
>
> > >
> > > I've seen us merge different named structs which happen to reside
> > > on the same variant list. That's bogus, not only because we are
> > > adjusting TYPE_MAIN_VARIANT during incremental type-merging and
> > > fixup, so computing a persis
On Tue, 2011-05-17 at 11:03 +0200, Richard Guenther wrote:
> On Mon, May 16, 2011 at 7:30 PM, William J. Schmidt
> wrote:
> > Richi, thank you for the detailed review!
> >
> > I'll plan to move the power-series expansion into the existing IL walk
> > during pass_cse_sincos. As part of this, I'll
> 2011-05-16 Kai Tietz
>
> PR middle-end/48989
> * gcc-interface/trans.c (Exception_Handler_to_gnu_sjlj): Use
> boolean_false_node instead of integer_zero_node.
> (convert_with_check): Likewise.
> * gcc-interface/decl.c (choices_to_gnu): Likewise.
OK for this part.
This fixes an oversight in the new SCC hash mixing code - we of course
need to return the adjusted hash of our type, not the purely local one.
There's still something weird going on, hash values somehow depend
on the order we feed it types ...
Bootstrapped on x86_64-unknown-linux-gnu, testing in
2011/5/17 Eric Botcazou :
>> 2011-05-16 Kai Tietz
>>
>> PR middle-end/48989
>> * gcc-interface/trans.c (Exception_Handler_to_gnu_sjlj): Use
>> boolean_false_node instead of integer_zero_node.
>> (convert_with_check): Likewise.
>> * gcc-interface/decl.c (choices_to_gnu
On Tue, May 17, 2011 at 3:29 AM, Richard Guenther wrote:
> On Mon, 16 May 2011, H.J. Lu wrote:
>
>> On Mon, May 16, 2011 at 7:17 AM, Richard Guenther wrote:
>> >
>> > The following patch improves hashing types by re-instantiating the
>> > patch that makes us visit aggregate target types of pointe
On Tue, May 17, 2011 at 5:59 AM, H.J. Lu wrote:
> On Tue, May 17, 2011 at 3:29 AM, Richard Guenther wrote:
>> On Mon, 16 May 2011, H.J. Lu wrote:
>>
>>> On Mon, May 16, 2011 at 7:17 AM, Richard Guenther wrote:
>>> >
>>> > The following patch improves hashing types by re-instantiating the
>>> > p
On Tue, May 17, 2011 at 3:01 PM, H.J. Lu wrote:
> On Tue, May 17, 2011 at 5:59 AM, H.J. Lu wrote:
>> On Tue, May 17, 2011 at 3:29 AM, Richard Guenther wrote:
>>> On Mon, 16 May 2011, H.J. Lu wrote:
>>>
On Mon, May 16, 2011 at 7:17 AM, Richard Guenther
wrote:
>
> The followi
On Tue, May 17, 2011 at 6:03 AM, Richard Guenther
wrote:
> On Tue, May 17, 2011 at 3:01 PM, H.J. Lu wrote:
>> On Tue, May 17, 2011 at 5:59 AM, H.J. Lu wrote:
>>> On Tue, May 17, 2011 at 3:29 AM, Richard Guenther wrote:
On Mon, 16 May 2011, H.J. Lu wrote:
> On Mon, May 16, 2011 at
On Wed, Apr 27, 2011 at 10:54 AM, Xinliang David Li wrote:
> Hi please review the trivial patch below. It reduces race conditions
> in value profiling. Another trivial change (to initialize
> function_list struct) is also included.
>
> Bootstrapped and regression tested on x86-64/linux.
>
> Thanks
> Hmm, sad. As the a check in tree-cfg for truth-expressions about
> having type-precision of 1 would be a good way. What is actual the
> cause for not setting type-precision here?
But we are setting it:
/* In Ada, we use an unsigned 8-bit type for the default boolean type. */
boolean_type_
So maybe this patch adding a comment on calculate_dominance_info is more
adapted.
ChangeLog:
2011-05-17 Pierre Vittet
* dominance.c (calculate_dominance_info): Add comment
precising when to free with free_dominance_info
contributor number: 634276
Index: gcc/dominance.c
===
Hi Richard, Hi Jeff, Hi Alex,
Here is another MN10300 patch. This ones adds support for TLS. I
must confess that I did not actually write this code - DJ did - but I
have been asked to submit it upstream, so here goes:
OK to apply ?
Cheers
Nick
gcc/ChangeLog
2011-05-17 DJ Delorie
Quite obvious if you look at it for the 100th time...
Richard.
2011-05-17 Richard Guenther
* gimple.c (type_hash_pair_compare): Fix comparison.
Index: gcc/gimple.c
===
--- gcc/gimple.c(revision 173830)
+++ gcc/g
This patch cleans up ARM handling of various options, making
enumerated options that were handled in arm_option_override use Enum
instead (except for -mfpu=, to be handled in a subsequent patch) and
using UInteger for -mstructure-size-boundary=.
-mfp= and -mfpe= (legacy aliases) are converted into
On 05/10/2011 04:18 PM, Nathan Froyd wrote:
> On 03/10/2011 11:23 PM, Nathan Froyd wrote:
>> After all that, we can finally make tree_exp inherit from typed_tree.
>> Quite anticlimatic.
>
> Ping. http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00559.html
Ping^2.
-Nathan
On Thu, 2011-05-05 at 09:30 +0200, Corinna Vinschen wrote:
> [Please keep me CCed, I'm not subscribed to gcc-patches. Thank you]
>
> Hi,
>
> the definition of psignal in libiberty is
>
>void psignal (int, char *);
>
> The correct definition per POSIX is
>
>void psignal (int, const ch
> > * strsignal.c (psignal): Change second parameter to const char *.
> > Fix comment accordingly.
> >
>
> OK.
I had argued against this patch:
http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00439.html
The newlib change broke ALL released versions of gcc, and the above
patch does NOT fi
2011/5/17 Eric Botcazou :
>> Hmm, sad. As the a check in tree-cfg for truth-expressions about
>> having type-precision of 1 would be a good way. What is actual the
>> cause for not setting type-precision here?
>
> But we are setting it:
>
> /* In Ada, we use an unsigned 8-bit type for the default
On Tue, 2011-05-17 at 11:52 -0400, DJ Delorie wrote:
> > > * strsignal.c (psignal): Change second parameter to const char *.
> > > Fix comment accordingly.
> > >
> >
> > OK.
>
> I had argued against this patch:
>
> http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00439.html
>
> The newlib cha
On May 17 16:33, Richard Earnshaw wrote:
>
> On Thu, 2011-05-05 at 09:30 +0200, Corinna Vinschen wrote:
> > [Please keep me CCed, I'm not subscribed to gcc-patches. Thank you]
> >
> > Hi,
> >
> > the definition of psignal in libiberty is
> >
> >void psignal (int, char *);
> >
> > The corr
On May 17 17:07, Richard Earnshaw wrote:
>
> On Tue, 2011-05-17 at 11:52 -0400, DJ Delorie wrote:
> > > > * strsignal.c (psignal): Change second parameter to const char
> > > > *.
> > > > Fix comment accordingly.
> > > >
> > >
> > > OK.
> >
> > I had argued against this patch:
> So regardless of whether the changes to newlib are a good idea or not, I
> think the fix to libiberty is still right.
Irrelevent. I said I'd accept that change *after* the real problem is
fixed. The real problem hasn't been fixed.
The real problem is that libibery should NOT INCLUDE PSIGNAL
> Thanks. I just have no check in rights to the gcc repository. I
> applied the change to the sourceware CVS repository but for gcc I
> need a proxy.
Please, never apply libiberty patches only to src. They're likely to
get deleted by the robomerge. The rule is: gcc only, or both at the
same t
> What I don't understand is why the newlib change broke older compilers.
Older compilers have the older libiberty. At the moment, libiberty
cannot be built by *any* released gcc, because you cannot *build* any
released gcc, because it cannot build its target libiberty.
> The function has been
On 05/14/2011 09:40 PM, Janne Blomqvist wrote:
Hi,
the current version of showing the backtrace is not async-signal-safe
as it uses backtrace_symbols() which, in turn, uses malloc(). The
attached patch changes the backtrace printing functionality to instead
use backtrace_symbols_fd() and pipes.
Hello!
2011-05-16 Uros Bizjak
* config/i386/i386-protos.h (output_fix_trunc): Change arg 3 to bool.
(output_fp_compare): Change args 3 and 4 to bool.
(ix86_expand_call): Change arg 6 to bool.
(ix86_attr_length_immediate_default): Change arg 2 to bool.
(i
Hello!
2011-05-17 Uros Bizjak
* ipa-inline-analysis.c (inline_node_duplication_hook): Initialize
info->entry with 0
* tree-inline.c (maybe_inline_call_in_expr): Initialize
id.transform_lang_insert_block with NULL.
Tested on x86_64-pc-linux-gnu {, m32} with --e
This patch correct a bug in the current revision of MELT, which was
preventing MELT to run correctly.
This was a path problem in gcc/Makefile.in (melt-modules/ and
melt-modules.mk) were not found.
My contributor number is 634276.
changelog :
2011-05-17 Pierre Vittet
* Makefile.
On 05/17/2011 07:50 PM, Toon Moene wrote:
On 05/14/2011 09:40 PM, Janne Blomqvist wrote:
Hi,
the current version of showing the backtrace is not async-signal-safe
as it uses backtrace_symbols() which, in turn, uses malloc(). The
attached patch changes the backtrace printing functionality to i
On Tue, 17 May 2011 21:30:44 +0200
Pierre Vittet wrote:
> This patch correct a bug in the current revision of MELT, which was
> preventing MELT to run correctly.
>
> This was a path problem in gcc/Makefile.in (melt-modules/ and
> melt-modules.mk) were not found.
>
> My contributor number is 6
On 05/17/2011 08:32 PM, Uros Bizjak wrote:
Tested on x86_64-pc-linux-gnu {, m32} with --enable-build-with-cxx.
Committed to mainline SVN as obvious.
Does that mean that I can now remove the --disable-werror from my daily
C++ bootstrap run ?
It's great that some people understand the intrica
I've applied the patch below to restore -Werror MIPS builds.
Tested on mips64-linux-gnu.
Richard
gcc/
* config/mips/mips.c (mips_handle_option): Remove unused variable.
Index: gcc/config/mips/mips.c
===
--- gcc/config/mips/
This patch fixes an obvious problem: the fma4_fmsubadd/fma4_fmaddsub
instruction templates don't generate vfmsubaddpd/vfmaddsubpd because
they don't use
This passes bootstrap on x86_64 on trunk. Okay to commit?
BTW, I'm testing on gcc-4_6-branch. Should I post a different patch
thread, or just
Hi,
this time too, took the occasion to add the get(tuple&&) bits. Tested
x86_64-linux, committed.
Paolo.
///
2011-05-17 Paolo Carlini
* include/std/tuple: Use noexcept where appropriate.
(tuple<>::swap): Rework implementation.
(_Head_base<>::_M_swa
PR 49026 identified testsuite regressions when mfpmath= is set by
target attributes, that for some reason appear on x86_64-darwin but
not x86_64-linux.
This patch fixes one place where I failed to preserve the logic of
this attribute handling, and restores the code generated for the
testcase to th
On Tue, May 17, 2011 at 2:46 PM, Toon Moene wrote:
> On 05/17/2011 08:32 PM, Uros Bizjak wrote:
>
>> Tested on x86_64-pc-linux-gnu {, m32} with --enable-build-with-cxx.
>> Committed to mainline SVN as obvious.
>
> Does that mean that I can now remove the --disable-werror from my daily C++
> bootst
You will have a followup patch to override arm defaults, right? Ok for
google/main.
Thanks,
David
On Tue, May 17, 2011 at 9:29 PM, Mark Heffernan wrote:
> This tiny change improves the size estimation for inlining and results in an
> average 1% size reduction and a small (maybe 0.25% geomean) p
This small patch greatly expands the function size limits for inlining
with FDO/LIPO. With profile information, the inliner is much more
selective and precise and so the limits can be increased with less
worry that functions and total code size will blow up. This speeds up
x86-64 internal benchma
Hi,
This is the first part of reduction support in loop-aware SLP. The
purpose of the patch is to handle "unrolled" reductions such as:
#a1 = phi
...
a2 = a1 + x
...
a3 = a2 + y
...
a5 = a4 + z
Such sequence of statements is gathered into a reduction chain and
serves as a root for an SLP instan
This part adds the actual code for reduction support.
Bootstrapped and tested on powerpc64-suse-linux.
I am planning to apply it later today.
Ira
ChangeLog:
PR tree-optimization/41881
* tree-vectorizer.h (struct _loop_vec_info): Add new field
reduction_chains along with a macro
Hi!
When an addressable var is optimized into non-addressable, we didn't
clean up MEM_REFs containing ADDR_EXPR of such VARs in debug stmts. This
got later on folded into the var itself and caused ssa verification errors.
Fixed by trying to rewrite it and if it fails, resetting.
Bootstrapped/reg
Hi!
This patch optimizes away unneeded DW_OP_GNU_converts. mem_loc_descriptor
attempts to keep the operands signed when it returns, if next op
needs it unsigned again with the same size, there might be useless
converts. The patch won't change DW_OP_GNU_convert to integral from
non-integral (so t
To make consistent inline decisions between profile-gen and
profile-use, probably better to check these two:
flag_profile_arcs and flag_branch_probabilities. -fprofile-use
enables profile-arcs, and value profiling is enabled only when
edge/branch profiling is enabled (so no need to be checked).
2011/5/16 Richard Guenther :
> On Mon, May 16, 2011 at 3:45 PM, Michael Matz wrote:
>> Hi,
>>
>> On Mon, 16 May 2011, Richard Guenther wrote:
>>
>>> > I think conversion _to_ BOOLEAN_TYPE shouldn't be useless, on the
>>> > grounds that it requires booleanization (at least conceptually), i.e.
>>> >
71 matches
Mail list logo
