Various minor speed-ups

Hello list, the followup patches are a selection of minor changes introduced in various times during my GSOC project. They mostly are simple or not that important to be posted alone, so I'll post them alltogether under this thread. Nevertheless they have been carefully selected from a pool of

mem_attrs_htab

2011-08-22 Dimitrios Apostolou * emit-rtl.c (mem_attrs_htab_hash): Hash massively by calling iterative_hash(). We disregard the offset,size rtx fields of the mem_attrs struct, but overall this hash is a *huge* improvement to the previous one, it reduces the col

graphds.[ch]: alloc_pool for edges

free() was called way too often before, this patch reduces it significantly. Minor speed-up here too, I don't mention it individually since numbers are within noise margins. 2011-08-22 Dimitrios Apostolou * graphds.h (struct graph): Added edge_pool as a pool for allocating

tree-ssa*: reduce malloc() calls by preallocating hot VECs on the stack

2011-08-22 Dimitrios Apostolou Allocate some very frequently used vectors on the stack: * vecir.h: Defined a tree vector on the stack. * tree-ssa-sccvn.c (print_scc, sort_scc, process_scc) (extract_and_process_scc_for_name): Allocate the scc vector on the

tree-ssa-structalias.c: alloc_pool for struct equiv_class_label

2011-08-22 Dimitrios Apostolou * tree-ssa-structalias.c (equiv_class_add) (perform_var_substitution, free_var_substitution_info): Created a new equiv_class_pool allocator pool for struct equiv_class_label. Changed the pointer_equiv_class_table and locat

[PATCH] make assign_hard_reg's saved_nregs conditional to unbreak ARM bootstrap (PR50146)

As described in PR50146, a recent change to ira-color.c caused trunk to fail to bootstrap on ARM. The issue is that a new variable saved_nregs is declared unconditionally but used #ifndef HONOR_REG_ALLOC_ORDER. Since the ARM backend defines HONOR_REG_ALLOC_ORDER, an 'unused variable' warning resu

Re: mem_attrs_htab

On Mon, Aug 22, 2011 at 10:32:35AM +0300, Dimitrios Apostolou wrote: > --- gcc/emit-rtl.c2011-05-29 17:40:05 + > +++ gcc/emit-rtl.c2011-08-21 04:44:25 + > @@ -256,11 +256,10 @@ mem_attrs_htab_hash (const void *x) > { >const mem_attrs *const p = (const mem_attrs *) x; > > - r

Re: Various minor speed-ups

2011-08-22 Dimitrios Apostolou * tree-ssa-pre.c (phi_trans_add, init_pre, fini_pre): Added a pool for phi_translate_table elements to avoid free() calls from htab_delete(). === modified file 'gcc/tree-ssa-pre.c' --- gcc/tree-ssa-pre.c 2011-05-04 09:04:53 + +++ gc

Re: graphds.[ch]: alloc_pool for edges

On Mon, Aug 22, 2011 at 10:37:58AM +0300, Dimitrios Apostolou wrote: > --- gcc/graphds.h 2009-02-20 15:20:38 + > +++ gcc/graphds.h 2011-08-19 16:44:41 + > @@ -18,6 +18,10 @@ You should have received a copy of the G > along with GCC; see the file COPYING3. If not see >

Re: tree-ssa-structalias.c: alloc_pool for struct equiv_class_label

Forgot the patch... On Mon, 22 Aug 2011, Dimitrios Apostolou wrote: 2011-08-22 Dimitrios Apostolou * tree-ssa-structalias.c (equiv_class_add) (perform_var_substitution, free_var_substitution_info): Created a new equiv_class_pool allocator pool for struct equi

Re: mem_attrs_htab

Hi Jakub, I forgot to mention that all patches are against mid-July trunk, I was hoping I'd have no conflicts. Anyway thanks for letting me know, if there are conflicts with my other patches please let me know, and I'll post an updated version at a later date. All your other concerns are val

Re: mem_attrs_htab

On Mon, Aug 22, 2011 at 10:58:48AM +0300, Dimitrios Apostolou wrote: > the future. I didn't like hashing addresses either, and I was > surprised I saw no regressions. Hashing on the expr address as well just results in smaller sharing in the hash table (i.e. if the expr has different address, but

Re: Various minor speed-ups

For whoever is concerned about memory usage, I didn't measure a real increase, besides a few KB. These are very hot allocation pools and allocating too many blocks of 10 elements is suboptimal. 2011-08-22 Dimitrios Apostolou * cselib.c (cselib_init): Increased initial size of elt_

cse.c: preferable()

Attached patch is also posted at bug #19832 and I think resolves it, as well as /maybe/ offers a negligible speedup of 3-4 M instr or a couple milliseconds. I also post it here for comments. 2011-08-13 Dimitrios Apostolou * cse.c (preferable): Make it more readable and slightly faster,

Re: Use of vector instructions in memmov/memset expanding

Ping. On 18 July 2011 15:00, Michael Zolotukhin wrote: > Here is a summary - probably, it doesn't cover every single piece in > the patch, but I tried to describe the major changes. I hope this will > help you a bit - and of course I'll answer your further questions if > they appear. > > The chan

Re: [PATCH v3, i386] BMI2 support for GCC, mulx, rorx, x part

On Sun, Aug 21, 2011 at 1:39 PM, Uros Bizjak wrote: > This is the third version of BMI2 support that includes generation of > mulx, rorx, x part. This patch includes all comments on > previous version, splits all insn post-reload, uses "enable" attribute > and avoids new register modifiers. As a

Re: [patch, committed] gfortran.dg/graphite/interchange-1.f: Remove xfail

Tobias, > I saw that the test case now XPASSes and I find also some xpass in > gcc-testresult. (Not for all, but I think those do not build graphite.) > > I think the XPASS is due to > http://gcc.gnu.org/ml/fortran/2011-08/msg00023.html This is PR tree-optimization/50124. Rainer -- ---

Re: [PATCH] make assign_hard_reg's saved_nregs conditional to unbreak ARM bootstrap (PR50146)

On Mon, Aug 22, 2011 at 09:46:17AM +0200, Mikael Pettersson wrote: > Patch was pre-approved by Vladimir Makarov in the PR trail, but I don't > have svn write access so I'll need help to commit it. Committed, thanks. Jakub

[trans-mem] Use __x86_64__ instead of __LP64__.

Use __x86_64__ instead of __LP64__ in setjmp/longjmp and TLS definitions. H.J.: Is that sufficient for x32, or do we need entirely different code? If so, can you please provide the required changes? Otherwise, OK for branch? commit 5337bae3f70d53e463d09e8d6806826876b0da8a Author: Torvald Riegel

Re: Dump stats about hottest hash tables when -fmem-report

Hello, I'm attaching here the final version of statistics dumping, I think I made some stylistic/insignificant changes. Tested on i386 and x86_64. I have withheld the hash table size changes, so please apply if you find everything good. Would you agree on a future patch that would make such

Re: tree-ssa*: reduce malloc() calls by preallocating hot VECs on the stack

On Mon, Aug 22, 2011 at 9:43 AM, Dimitrios Apostolou wrote: > > 2011-08-22  Dimitrios Apostolou   > >        Allocate some very frequently used vectors on the stack: >        * vecir.h: Defined a tree vector on the stack. >        * tree-ssa-sccvn.c (print_scc, sort_scc, process_scc) >        (ext

Re: graphds.[ch]: alloc_pool for edges

On Mon, Aug 22, 2011 at 9:37 AM, Dimitrios Apostolou wrote: > free() was called way too often before, this patch reduces it significantly. > Minor speed-up here too, I don't mention it individually since numbers are > within noise margins. As there is no re-use in this pool the natural allocator

Re: tree-ssa-structalias.c: alloc_pool for struct equiv_class_label

On Mon, Aug 22, 2011 at 9:46 AM, Dimitrios Apostolou wrote: > > 2011-08-22  Dimitrios Apostolou   > >        * tree-ssa-structalias.c (equiv_class_add) >        (perform_var_substitution, free_var_substitution_info): Created a >        new equiv_class_pool allocator pool for struct >        equiv_

[trans-mem] Move x86 TLS definition to linux/x86.

A small change. OK for branch? commit b9db8481779fc5a4069ac36505bd6cce8da971a1 Author: Torvald Riegel Date: Mon Aug 22 11:52:00 2011 +0200 Move x86 TLS definition to linux/x86. * config/x86/tls.h: Moved to ... * config/linux/x86/tls.h: ... here. diff --git a/libitm/con

Re: [ARM] Model automodified addresses in the Cortex A8 and A9 schedulers

> Tested on arm-linux-gnueabi.  OK to install? > gcc/ >* config/arm/arm-protos.h (arm_writeback_dep): Declare. > (arm_writeback_only_dep): Likewise. > * config/arm/arm.c (arm_writeback_dep): New function. > (arm_writeback_only_dep_1, arm_writeback_only_dep): Likewise. >

Re: mem_attrs_htab

On Mon, Aug 22, 2011 at 10:04 AM, Jakub Jelinek wrote: > On Mon, Aug 22, 2011 at 10:58:48AM +0300, Dimitrios Apostolou wrote: >> the future. I didn't like hashing addresses either, and I was >> surprised I saw no regressions. > > Hashing on the expr address as well just results in smaller sharing

Re: Various minor speed-ups

On Mon, Aug 22, 2011 at 9:50 AM, Dimitrios Apostolou wrote: > > 2011-08-22  Dimitrios Apostolou   > >        * tree-ssa-pre.c (phi_trans_add, init_pre, fini_pre): Added a pool >        for phi_translate_table elements to avoid free() calls from >        htab_delete(). Ok if bootstrap and test pas

Re: mem_attrs_htab

On Mon, Aug 22, 2011 at 11:57:18AM +0200, Richard Guenther wrote: > And at some point the idea popped up to just dump this whole re-using > mem-attrs. There is at most a single function in RTL but the whole program > is available in SSA, so the memory overhead must be small. Some functions are ex

Re: tree-ssa-structalias.c: alloc_pool for struct equiv_class_label

On Mon, 22 Aug 2011, Richard Guenther wrote: On Mon, Aug 22, 2011 at 9:46 AM, Dimitrios Apostolou wrote: 2011-08-22  Dimitrios Apostolou          * tree-ssa-structalias.c (equiv_class_add)        (perform_var_substitution, free_var_substitution_info): Created a        new equiv_class_pool al

[PATCH] Fix PR50067

Applied. Richard. 2011-08-22 Richard Guenther PR testsuite/50145 * gcc.dg/torture/pr50067-1.c: Run on little-endian systems only. * gcc.dg/torture/pr50067-2.c: Likewise. Index: gcc/testsuite/gcc.dg/torture/pr50067-1.c =

[var-tracking] small speed-ups

Hello list, this patch has all of my changes to var-tracking that I believe are worth keeping. These are all minor changes not touching algorithmic issues, I lost much time trying to understand what is actually done in var-tracking.c but I still don't get it. I wish there was some document de

Re: mem_attrs_htab

On Mon, Aug 22, 2011 at 12:07 PM, Jakub Jelinek wrote: > On Mon, Aug 22, 2011 at 11:57:18AM +0200, Richard Guenther wrote: >> And at some point the idea popped up to just dump this whole re-using >> mem-attrs.  There is at most a single function in RTL but the whole program >> is available in SSA,

[patch] revert an obsolete part from the mips-triarch checkin

While looking at the multiarch patches, I noticed that a previous change is not necessary. MULTILIB_DEFAULTS is handled in config/mips/mips.h. Matthias gcc/ 2011-08-22 Matthias Klose Revert: 2011-07-11 Arthur Loiret Matthias Klose * config/mi

Re: [patch] revert an obsolete part from the mips-triarch checkin

Matthias Klose writes: > 2011-08-22 Matthias Klose > > Revert: > 2011-07-11 Arthur Loiret > Matthias Klose > * config/mips/t-linux64 (MULTILIB_DIRNAMES): Set to 'n32 . 64' if > tm_defines contains MIPS_ABI_DEFAULT ABI_32, to follow the glibc >

[PATCH] void dangling line table after loading pch

Hello, In c_common_read_pch when gt_pch_restore loads a new pch, the previous line table (referenced from the global 'line_table') is garbage-collected and a new one is built. As the global instance of cpp_reader referenced by the local variable 'pfile' has a pfile->line_table member that referen

Re: Vector Comparison patch

On Mon, Aug 22, 2011 at 12:53 AM, Artem Shinkarov wrote: > Richard > > I formalized an approach a little-bit, now it works without target > hooks, but some polishing is still required. I want you to comment on > the several important approaches that I use in the patch. > > So how does it work. > 1

[var-tracking] [not-good!] disable shared_hash and other simplifications

Hello, the attached patch applies after my previous one, and actually cancels all runtime gains from it. It doesn't make things worse than initially, so it's not *that* bad. While trying to understand var-tracking I deleted the whole shared hash table concept and some other indirections. It

Re: Dump stats about hottest hash tables when -fmem-report

I should note here that specialised hash-tables in pointer-set.c have a load-factor of at most 25%. Also another very fast hash table I've studied, dense_hash_map from google's sparse_hash_table, has a load factor of 50% max. As I understand it a good hash function gives a perfectly random val

Re: [var-tracking] [not-good!] disable shared_hash and other simplifications

On Mon, Aug 22, 2011 at 02:26:58PM +0300, Dimitrios Apostolou wrote: > the attached patch applies after my previous one, and actually > cancels all runtime gains from it. It doesn't make things worse than > initially, so it's not *that* bad. You should really test it on the testcases which lead to

Re: Dump stats about hottest hash tables when -fmem-report

On Mon, Aug 22, 2011 at 1:37 PM, Dimitrios Apostolou wrote: > I should note here that specialised hash-tables in pointer-set.c have a > load-factor of at most 25%. Also another very fast hash table I've studied, > dense_hash_map from google's sparse_hash_table, has a load factor of 50% > max. > >

Re: [var-tracking] small speed-ups

On Mon, Aug 22, 2011 at 01:30:33PM +0300, Dimitrios Apostolou wrote: > --- gcc/var-tracking.c2011-06-03 01:42:31 + > +++ gcc/var-tracking.c2011-08-22 09:52:08 + > @@ -1069,14 +1067,14 @@ adjust_insn (basic_block bb, rtx insn) > static inline bool > dv_is_decl_p (decl_or_va

Re: Vector Comparison patch

On Mon, Aug 22, 2011 at 12:25 PM, Richard Guenther wrote: > On Mon, Aug 22, 2011 at 12:53 AM, Artem Shinkarov > wrote: >> Richard >> >> I formalized an approach a little-bit, now it works without target >> hooks, but some polishing is still required. I want you to comment on >> the several import

[dwarf2out, elfos] Output assembly faster

Hello again, most of this patch was posted at the beginning of my GSOC adventure and primarily is about replacing fprintf() calls with custom faster ones. From that time I changed minor things you suggested, omitted some complexities that offered minor speed-up, and made the code as clear as p

Re: GIMPLE and intent of variables

Thank you for all the answers. Now I have another problem. When I reach a function call during statement iteration, I want to go to this function's code. if (is_gimple_call(stmt)) { tree fndecl = gimple_call_fndecl(stmt); // This returns function_decl ;-)

Re: GIMPLE and intent of variables

On Mon, Aug 22, 2011 at 2:21 PM, Mateusz Grabowski wrote: > > Thank you for all the answers. Now I have another problem. > > When I reach a function call during statement iteration, I want to go to > this function's code. > > if (is_gimple_call(stmt)) { >                tree fndecl = gimple_call_f

Re: GIMPLE and intent of variables

Richard Guenther-2 wrote: > > > The latter. > > But how to do it? I want to have all functions after SSA pass, but before any optimizations. Maybe you could tell me how to enforce it (or even better - a small example)? Thanks in advance. -- View this message in context: http://old.nabble.

Re: [trans-mem] Use __x86_64__ instead of __LP64__.

On Mon, Aug 22, 2011 at 2:42 AM, Torvald Riegel wrote: > Use __x86_64__ instead of __LP64__ in setjmp/longjmp and TLS > definitions. > > H.J.: Is that sufficient for x32, or do we need entirely different code? > If so, can you please provide the required changes? > I need to take a look. Thanks.

Re: [DF] [performance] generate DF_REF_BASE REFs in REGNO order

Hi Steven, On Mon, 1 Aug 2011, Steven Bosscher wrote: On Sun, Jul 31, 2011 at 11:59 PM, Steven Bosscher wrote: On Fri, Jul 29, 2011 at 11:48 PM, Steven Bosscher wrote: I'll see if I can test the patch on the compile farm this weekend, just to be sure. Bootstrap on ia64-unknown-linux-gnu is

Re: [PATCH, testsuite, i386] AVX2 support for GCC

On Mon, Aug 22, 2011 at 6:18 AM, Kirill Yukhin wrote: > Hi, > thanks for input, Uros. Spaces were fixed. > > Updated patch is attached. ChangeLog entry is attached. > > Could anybody please commit it? > I checked in for you. -- H.J.

Re: [PATCH, testsuite, i386] AVX2 support for GCC

Thanks! K On Mon, Aug 22, 2011 at 5:57 PM, H.J. Lu wrote: > On Mon, Aug 22, 2011 at 6:18 AM, Kirill Yukhin > wrote: >> Hi, >> thanks for input, Uros. Spaces were fixed. >> >> Updated patch is attached. ChangeLog entry is attached. >> >> Could anybody please commit it? >> > > I checked in for y

[testsuite,committed]: Add require scheduling to gcc.dg/pr49994-[23].c

http://gcc.gnu.org/viewcvs?view=revision&revision=177954 Committed that patchlet as obvious. testsuite/ * gcc.dg/pr49994-2.c: Add dg-require-effective-target scheduling. * gcc.dg/pr49994-3.c: Ditto. Johann Index: ChangeLog ===

Re: PING: PATCH: PR target/46770: Use .init_array/.fini_array sections

On Sun, Aug 21, 2011 at 10:37 PM, Jakub Jelinek wrote: > On Sun, Aug 21, 2011 at 05:09:59PM -0700, H.J. Lu wrote: >> I didn't know .init_array section was enabled for AIX.  Does this patch >> work for you? > > Some ELF targets (e.g. arm*-linux*) don't use elfos.h.  IMHO you should > instead add >

Re: [4.7][google]Support for getting CPU type and feature information at run-time. (issue4893046)

Hi, On Sun, 21 Aug 2011, Richard Guenther wrote: > On Sat, Aug 20, 2011 at 11:02 PM, Richard Henderson wrote: > > On 08/19/2011 02:04 AM, Richard Guenther wrote: > >> So make sure that __cpu_indicator initially has a conservative correct > >> value?  I'd still prefer the constructor-in-libgcc op

Re: [4.7][google]Support for getting CPU type and feature information at run-time. (issue4893046)

On Mon, Aug 22, 2011 at 7:07 AM, Michael Matz wrote: > Hi, > > On Sun, 21 Aug 2011, Richard Guenther wrote: > >> On Sat, Aug 20, 2011 at 11:02 PM, Richard Henderson wrote: >> > On 08/19/2011 02:04 AM, Richard Guenther wrote: >> >> So make sure that __cpu_indicator initially has a conservative cor

Re: GIMPLE and intent of variables

On Mon, Aug 22, 2011 at 2:57 PM, Mateusz Grabowski wrote: > > > Richard Guenther-2 wrote: >> >> >> The latter. >> >> > > But how to do it? I want to have all functions after SSA pass, but before > any optimizations. Maybe you could tell me how to enforce it (or even better > - a small example)? >

Re: [PATCH 4/7] Support -fdebug-cpp option

> "Jakub" == Jakub Jelinek writes: Jakub> For ccache and friends I think it would be better to have a Jakub> preprocessing mode that would output all lines as is (i.e. no Jakub> macro replacement), except for processing #include/#include_next Jakub> directives. That exists -- -fdirectives-on

[PATCH] Fix a RTL sharing problem with CALL_INSN_FUNCTION_USAGE (PR middle-end/48722)

Hi! As the testcase below shows (on i686-linux or x86_64-linux -m32), we don't unshare expressions in CALL_INSN_FUNCTION_USAGE, which with entry_value support now include MEMs. The invalid sharing then can lead to changes in unrelated insns affecting a call insn (or vice versa), which results in

[PATCH] Fix ICEs in get_bit_range (PR middle-end/50141)

Hi! DECL_THREAD_LOCAL_P may be used only on VAR_DECLs, not other decls like PARM_DECL, RESULT_DECL etc. Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2011-08-22 Jakub Jelinek PR middle-end/50141 * expr.c (get_bit_range): Only use DECL_THREA

[PATCH] Fix ICEs in vect_finish_stmt_generation (PR tree-optimization/50133)

Hi! The following testcase ICEs, because gsi_end_p (*gsi) and thus there is no stmt after it from which to copy over the location. As can be seen in the PR, we could do ugly hacks to retrieve locus from previous stmt (non-debug of course) instead, but I'm probably missing something obvious why we

[C++ PATCH] Clear TYPE_TRANSPARENT_AGGR if there are no fields (PR c++/46862)

Hi! TYPE_TRANSPARENT_AGGR types are passed and mangled as its first field. But if somebody errorneously doesn't put any types in its definition, the FE marks it TYPE_TRANSPARENT_AGGR early (e.g. even on a forward declaration), but during mangling or in middle-end when trying to find out how it wil

Re: [PATCH] void dangling line table after loading pch

On 11-08-22 07:10 , Dodji Seketeli wrote: Hello, In c_common_read_pch when gt_pch_restore loads a new pch, the previous line table (referenced from the global 'line_table') is garbage-collected and a new one is built. As the global instance of cpp_reader referenced by the local variable 'pfile'

Re: [PATCH 4/7] Support -fdebug-cpp option

On Mon, Aug 22, 2011 at 08:16:45AM -0600, Tom Tromey wrote: > > "Jakub" == Jakub Jelinek writes: > > Jakub> For ccache and friends I think it would be better to have a > Jakub> preprocessing mode that would output all lines as is (i.e. no > Jakub> macro replacement), except for processing #in

Re: PING: PATCH: PR target/46770: Use .init_array/.fini_array sections

On Mon, Aug 22, 2011 at 7:06 AM, H.J. Lu wrote: > On Sun, Aug 21, 2011 at 10:37 PM, Jakub Jelinek wrote: >> On Sun, Aug 21, 2011 at 05:09:59PM -0700, H.J. Lu wrote: >>> I didn't know .init_array section was enabled for AIX.  Does this patch >>> work for you? >> >> Some ELF targets (e.g. arm*-linu

Re: [PATCH] Fix ICEs in get_bit_range (PR middle-end/50141)

On Mon, Aug 22, 2011 at 4:18 PM, Jakub Jelinek wrote: > Hi! > > DECL_THREAD_LOCAL_P may be used only on VAR_DECLs, not other decls > like PARM_DECL, RESULT_DECL etc. > Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, > ok for trunk? Ok. Thanks, Richard. > 2011-08-22  Jakub J

Re: [PATCH] Fix ICEs in vect_finish_stmt_generation (PR tree-optimization/50133)

On Mon, Aug 22, 2011 at 4:22 PM, Jakub Jelinek wrote: > Hi! > > The following testcase ICEs, because gsi_end_p (*gsi) and thus > there is no stmt after it from which to copy over the location. > As can be seen in the PR, we could do ugly hacks to retrieve locus > from previous stmt (non-debug of c

Re: Vector Comparison patch

On Mon, Aug 22, 2011 at 2:05 PM, Artem Shinkarov wrote: > On Mon, Aug 22, 2011 at 12:25 PM, Richard Guenther > wrote: >> On Mon, Aug 22, 2011 at 12:53 AM, Artem Shinkarov >> wrote: >>> Richard >>> >>> I formalized an approach a little-bit, now it works without target >>> hooks, but some polishin

Re: PING: PATCH: PR target/46770: Use .init_array/.fini_array sections

On 08/22/2011 04:45 PM, H.J. Lu wrote: Can I check in this patch to address AIX issue first? I will submit a patch to test ".section .init_array" later? Thanks. Yes. Paolo

[pph] Fix x1dynarra1, x1dynarray2a and x1dynarray2b (issue4921051)

This patch fixes some template test cases. We were trying to expand functions that did not really need expanding (templates). This got me thinking that we are not approaching the expansion properly. We are trying to re-create all the cgraph creation done during the compilation of the header fi

Re: Vector Comparison patch

On Mon, Aug 22, 2011 at 4:01 PM, Richard Guenther wrote: > On Mon, Aug 22, 2011 at 2:05 PM, Artem Shinkarov > wrote: >> On Mon, Aug 22, 2011 at 12:25 PM, Richard Guenther >> wrote: >>> On Mon, Aug 22, 2011 at 12:53 AM, Artem Shinkarov >>> wrote: Richard I formalized an approach a

[pph] Re-organize pph_write_tree/pph_read_tree (issue4934045)

This patch refactors pph_write_tree and pph_read_tree so that we can reduce the amount of special casing we were doing. It first tries to handle nodes based on their tree code class. The only class that cannot be handled this way is tcc_exceptional, so we only deal with those nodes individually.

Re: Vector Comparison patch

On Mon, Aug 22, 2011 at 5:21 PM, Artem Shinkarov wrote: > On Mon, Aug 22, 2011 at 4:01 PM, Richard Guenther > wrote: >> On Mon, Aug 22, 2011 at 2:05 PM, Artem Shinkarov >> wrote: >>> On Mon, Aug 22, 2011 at 12:25 PM, Richard Guenther >>> wrote: On Mon, Aug 22, 2011 at 12:53 AM, Artem Shink

Re: [DF] [performance] generate DF_REF_BASE REFs in REGNO order

On Mon, 22 Aug 2011, Dimitrios Apostolou wrote: Hi Steven, On Mon, 1 Aug 2011, Steven Bosscher wrote: On Sun, Jul 31, 2011 at 11:59 PM, Steven Bosscher wrote: On Fri, Jul 29, 2011 at 11:48 PM, Steven Bosscher wrote: I'll see if I can test the patch on the compile farm this weekend, just to

Re: Vector Comparison patch

On Mon, Aug 22, 2011 at 4:34 PM, Richard Guenther wrote: > On Mon, Aug 22, 2011 at 5:21 PM, Artem Shinkarov > wrote: >> On Mon, Aug 22, 2011 at 4:01 PM, Richard Guenther >> wrote: >>> On Mon, Aug 22, 2011 at 2:05 PM, Artem Shinkarov >>> wrote: On Mon, Aug 22, 2011 at 12:25 PM, Richard Guen

Re: mem_attrs_htab

Hi, On Mon, 22 Aug 2011, Richard Guenther wrote: > > Some functions are extremely large though.  Do you mean that MEM > > itself would be enlarged to have the MEM_ATTRS field so that one > > operand is the address, then expr, then HWI size, offset, etc.? > >  Because if the mem attrs aren't sh

Re: Vector Comparison patch

On Mon, Aug 22, 2011 at 5:43 PM, Artem Shinkarov wrote: > On Mon, Aug 22, 2011 at 4:34 PM, Richard Guenther > wrote: >> On Mon, Aug 22, 2011 at 5:21 PM, Artem Shinkarov >> wrote: >>> On Mon, Aug 22, 2011 at 4:01 PM, Richard Guenther >>> wrote: On Mon, Aug 22, 2011 at 2:05 PM, Artem Shinkar

Re: PING: PATCH: PR target/46770: Use .init_array/.fini_array sections

On Sun, Aug 21, 2011 at 4:19 PM, David Edelsohn wrote: > This patch broke bootstrap on AIX.  It emits a ".section" op in > assembly but ".section" is an ELF syntax op not AIX XCOFF. > > FE..initialize_critical: >        .section        .init_array > > varasm.c should not be generating ELF ops for

Re: [PATCH] Fix ICEs in get_bit_range (PR middle-end/50141)

@@ -4354,7 +4354,8 @@ get_bit_range (unsigned HOST_WIDE_INT *b || TREE_CODE (innerdecl) == TARGET_MEM_REF) && !ptr_deref_may_alias_global_p (TREE_OPERAND (innerdecl, 0))) || (DECL_P (innerdecl) - && (DECL_THREAD_LOCAL_P (innerdecl) + && ((TREE_CODE (inne

Re: [4.7][google]Support for getting CPU type and feature information at run-time. (issue4893046)

Hi, On Mon, 22 Aug 2011, H.J. Lu wrote: > >> Oh, I thought it was data initialized by the constructor ... > > > > Sriramans patch right now has a function __cpu_indicator_init which is > > called from (adhoc constructed) ctors and that initializes variables > > __cpu_model and __cpu_features ;-)

Re: Vector Comparison patch

On Mon, Aug 22, 2011 at 4:50 PM, Richard Guenther wrote: > On Mon, Aug 22, 2011 at 5:43 PM, Artem Shinkarov > wrote: >> On Mon, Aug 22, 2011 at 4:34 PM, Richard Guenther >> wrote: >>> On Mon, Aug 22, 2011 at 5:21 PM, Artem Shinkarov >>> wrote: On Mon, Aug 22, 2011 at 4:01 PM, Richard Guent

Re: [4.7][google]Support for getting CPU type and feature information at run-time. (issue4893046)

On Mon, Aug 22, 2011 at 8:56 AM, Michael Matz wrote: > Hi, > > On Mon, 22 Aug 2011, H.J. Lu wrote: > >> >> Oh, I thought it was data initialized by the constructor ... >> > >> > Sriramans patch right now has a function __cpu_indicator_init which is >> > called from (adhoc constructed) ctors and th

Re: [pph] Fix x1dynarra1, x1dynarray2a and x1dynarray2b (issue4921051)

On Mon, Aug 22, 2011 at 8:22 AM, Diego Novillo wrote: > > This patch fixes some template test cases.  We were trying to > expand functions that did not really need expanding (templates).  This > got me thinking that we are not approaching the expansion properly. > > We are trying to re-create all

Re: [PATCH] void dangling line table after loading pch

Diego Novillo writes: > On 11-08-22 07:10 , Dodji Seketeli wrote: [...] >> gcc/ >> >> * c-family/c-pch.c (c_common_read_pch): Re-set line table right >> after reading in the pch. > > OK. Thanks, committed to revision r177964. -- Dodji

Re: PING: PATCH: PR target/46770: Use .init_array/.fini_array sections

On Sun, Aug 21, 2011 at 10:37 PM, Jakub Jelinek wrote: nd/or add another test to it that tests > that you can actually use > .section .init_array > and it will use correct section flags for the section. > We need this information in config.gcc. But config.gcc is used before assembler and readelf

Re: RFC: [build, ada] Centralize PICFLAG configuration

Paolo Bonzini writes: > On 08/19/2011 09:11 PM, Rainer Orth wrote: >> >> 2011-07-31 Rainer Orth >> >> config: >> * picflag.m4: New file. >> >> gcc: >> * configure.ac (GCC_PICFLAG_FOR_TARGET): Call it. >> (PICFLAG_FOR_TARGET): Substitute. >> * aclocal.m4: Regenerate.

Re: RFC: [build, ada] Centralize PICFLAG configuration

> Do I need to sync the config and libiberty parts to src manually or does > this happen by some sort of magic? intl/; config.rhost; libiberty/; libiberty's part of include/ gcc: http://gcc.gnu.org Changes need to be done in tandem with the official GCC sources or submit

Re: repost: [DF] Use HARD_REG_SETs instead of bitmaps

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/22/11 11:16, Dimitrios Apostolou wrote: > > Any updates will come as a followup to this thread. I still have to > do some testing on other platforms. Do we have access to any PA and > MIPS machinery? I also wanted to test on architecture with l

Re: PING: PATCH: PR target/46770: Use .init_array/.fini_array sections

On Mon, Aug 22, 2011 at 10:09 AM, H.J. Lu wrote: > On Sun, Aug 21, 2011 at 10:37 PM, Jakub Jelinek wrote: > nd/or add another test to it that tests >> that you can actually use >> .section .init_array >> and it will use correct section flags for the section. >> > > We need this information in con

[ping 2] [patch] attribute to reverse bitfield allocations

Ping 2 ? http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01889.html http://gcc.gnu.org/ml/gcc-patches/2011-07/msg02555.html

Re: [patch] support for multiarch systems

On 08/21/2011 02:14 AM, Matthias Klose wrote: On 08/20/2011 09:51 PM, Matthias Klose wrote: Multiarch [1] is the term being used to refer to the capability of a system to install and run applications of multiple different binary targets on the same system. The idea and name of multiarch date

Re: [var-tracking] [not-good!] disable shared_hash and other simplifications

On Mon, Aug 22, 2011 at 1:54 PM, Jakub Jelinek wrote: >> * From a very wide field of view, all this DF solving reminded me a >> lot of what I've seen in df-*.c. Why can't variable tracking be >> integrated in the main DF pass of the compiler, the one that happens >> *after* register allocation? >

Re: [var-tracking] [not-good!] disable shared_hash and other simplifications

On Mon, Aug 22, 2011 at 07:49:43PM +0200, Steven Bosscher wrote: > On Mon, Aug 22, 2011 at 1:54 PM, Jakub Jelinek wrote: > >> * From a very wide field of view, all this DF solving reminded me a > >> lot of what I've seen in df-*.c. Why can't variable tracking be > >> integrated in the main DF pass

Re: RFC: [build, ada] Centralize PICFLAG configuration

DJ Delorie writes: >> Do I need to sync the config and libiberty parts to src manually or does >> this happen by some sort of magic? > > > intl/; config.rhost; libiberty/; libiberty's part of include/ > gcc: http://gcc.gnu.org > Changes need to be done in tandem with the official GCC

[pph] Cleanup line_table and includes streaming (issue4921052)

This is a refactoring patch, it doesn't change/fix anything in pph itself. I extracted out/in logic for includes into their own functions. I removed the LINETAB parameter from in/out functions for the line_table as there is only one line_table and that's the only one we stream, the main/global

Re: [pph] Cleanup line_table and includes streaming (issue4921052)

On 11-08-22 14:20 , Gabriel Charette wrote: 2011-08-22 Gabriel Charette * pph-streamer-in.c (pph_loc_offset): Add FIXME to move this variable to pph_stream.encoder.r (pph_in_include): New. (pph_in_line_table_and_includes): Remove LINETAB parameter. Update

Re: [4.7][google]Support for getting CPU type and feature information at run-time. (issue4893046)

On Mon, Aug 22, 2011 at 9:02 AM, H.J. Lu wrote: > On Mon, Aug 22, 2011 at 8:56 AM, Michael Matz wrote: >> Hi, >> >> On Mon, 22 Aug 2011, H.J. Lu wrote: >> >>> >> Oh, I thought it was data initialized by the constructor ... >>> > >>> > Sriramans patch right now has a function __cpu_indicator_init

[PATCH, test, i386] Fix for PR50155

Hi, Attached fix for http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50155 ChangeLog entry: 2011-08-22 Kirill Yukhin PR target/50155 * config/i386/sse.md (VI1248_AVX2): New. (3): Update. (*3): Likewise. (_andnot3): Likewise. (avx2_pbroadcast): Likewi

Re: PING: PATCH: PR target/46770: Use .init_array/.fini_array sections

On Mon, 22 Aug 2011, H.J. Lu wrote: > On Sun, Aug 21, 2011 at 10:37 PM, Jakub Jelinek wrote: > nd/or add another test to it that tests > > that you can actually use > > .section .init_array > > and it will use correct section flags for the section. > > > > We need this information in config.gcc.

Re: [PATCH] PR middle-end/38509: add -Wfree-nonheap-object warning option

On 11-08-21 18:14 , Mark Heffernan wrote: Ping? Mark On Fri, Aug 12, 2011 at 9:41 AM, Mark Heffernan wrote: This patch adds an option for enabling/disabling the warning for attempting to free nonheap objects (PR/38509). The warning is imprecise and can issue false positives. Bootstrapped on

Re: PING: PATCH: PR target/46770: Use .init_array/.fini_array sections

On Mon, Aug 22, 2011 at 11:53 AM, Joseph S. Myers wrote: > On Mon, 22 Aug 2011, H.J. Lu wrote: > >> On Sun, Aug 21, 2011 at 10:37 PM, Jakub Jelinek wrote: >> nd/or add another test to it that tests >> > that you can actually use >> > .section .init_array >> > and it will use correct section flags

Re: [4.7][google]Support for getting CPU type and feature information at run-time. (issue4893046)

On Mon, Aug 22, 2011 at 11:50 AM, Sriraman Tallam wrote: > On Mon, Aug 22, 2011 at 9:02 AM, H.J. Lu wrote: >> On Mon, Aug 22, 2011 at 8:56 AM, Michael Matz wrote: >>> Hi, >>> >>> On Mon, 22 Aug 2011, H.J. Lu wrote: >>> >> Oh, I thought it was data initialized by the constructor ... > >

  1   2   >