Re: [patch] more bitmap obstacks
Steven Bosscher wrote: This reduces peak memory usage for the small test case of PR54146 Bootstrapped&tested on x86_64-unknown-linux-gnu. OK for trunk? I think it's your patch which breaks bootstrapping here: Checking multilib configuration for libgcc... ... checking for suffix of object files... configure: error: in `/projects/tob/gcc-git/gcc-build/x86_64-unknown-linux-gnu/libgcc': configure: error: cannot compute suffix of object files: cannot compile conftest.c: In Function »main«: conftest.c:7:1: internal compiler error: segmentation fault } ^ Program received signal SIGSEGV, Segmentation fault. 0x005bfa40 in bitmap_obstack_free (map=0x18693a0) at /projects/tob/gcc-git/gcc/gcc/bitmap.c:388 388 map->first = (bitmap_element *) map->obstack->heads; (gdb) p map->obstack $1 = (bitmap_obstack *) 0x9090909090909090 Thus, your patch assumes that malloc returns nullified memory, but e.g. with MALLOC_PERTURB_ set, that's not the case. Tobias
Re: [PATCH][C++] Get rid of TREE_CHAIN use for TREE_VEC (NON_DEFAULT_TEMPLATE_ARGS_COUNT)
On Fri, Aug 17, 2012 at 9:11 PM, Gabriel Dos Reis wrote: > On Fri, Aug 17, 2012 at 1:03 PM, Mike Stump wrote: >> On Aug 17, 2012, at 6:58 AM, Paolo Carlini wrote: >>> On 08/17/2012 01:26 PM, Richard Guenther wrote: This gets rid of this field, pushing it into a short int in tree_base (hopefully 2^16 non-defaulted template args are enough ...). >>> Honestly, I don't think it's a trivial issue. >> >> Love to hear from Jason, but, my take would be 2^16 should be enough for >> anyone. I think long before people hit that limit, they would merely >> aggregate arguments into classes and structures. I think in another 20-80 >> years, we might want to bump it back up to 32 bits, but... I think we can >> safely wait until we get a compelling bug report for it. > > C++11 says that an implementation should be able to handle at least 2^10 > template parameters, 2^12 members declared in a single class. I believe > that even for automatically generated programs, 2^16 is a good limit. I > suspect > that by the time that limit is a hindrance, C++ would have gone through > several > iterations and more importantly 128-bit integers would be common place, so > by that time we would have plenty of spare bits -- if we haven't already > restructured the tree data structures to use idiomatic C++ constructs that > are both more space and time efficient. > > This is a very long of saying "I am comfortable with the 2^16 restriction > on the number of template parameters. The patch needs to document > that in the usual .texi file." I searched for a place where we document GNU C++ implmenetation defined behavior / limits but didn't find it. Can you point me to the place where we document that the current limit is 2^31 - 1 _non defaulted_ template parameters? (It looks to me this whole non-defaulted-template-args stuff was just invented to avoid pretty-printing defaulted args, so it does not in any way present an implementation limit but only a possible bug in that we'd never pretty-print more than 2^31 - 1 non-defaulted template paramters in a diagnostic, but who wants to see 2^31 template parameters in a diagnostic anyways ...) Richard. > -- Gaby
Re: CXX conversion: min g++ version pre-requisite?
On Sat, Aug 18, 2012 at 3:36 AM, Gary Funck wrote: > > Paul Hargrove noted the following build failure on > an older x86-32 Linux (Redhat 8.0) system. > > g++ -c -g -O2 -DIN_GCC -fno-exceptions -fno-rtti -W -Wall > -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -fno-common > -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild > -I/usr/local/pkg/upc/nightly/compiler/gupc-src/gcc > -I/usr/local/pkg/upc/nightly/compiler/gupc-src/gcc/build > -I/usr/local/pkg/upc/nightly/compiler/gupc-src/gcc/../include > -I/usr/local/pkg/upc/nightly/compiler/gupc-src/gcc/../libcpp/include > -I/usr/local/pkg/gmp-4.2.4/include -I/usr/local/pkg/mpfr-2.4.2/include > -I/usr/local/pkg/mpc-0.8/include > -I/usr/local/pkg/upc/nightly/compiler/gupc-src/gcc/../libdecnumber > -I/usr/local/pkg/upc/nightly/compiler/gupc-src/gcc/../libdecnumber/bid > -I../libdecnumber\ > -o build/genoutput.o > /usr/local/pkg/upc/nightly/compiler/gupc-src/gcc/genoutput.c > /usr/local/pkg/upc/nightly/compiler/gupc-src/gcc/genoutput.c: In function > `void note_constraint(rtx_def*, int)': > /usr/local/pkg/upc/nightly/compiler/gupc-src/gcc/genoutput.c:1178: error: > reinterpret_cast from type `const char (*)[1]' to type `char*' casts away > constness > make[2]: *** [build/genoutput.o] Error 1 > make[2]: Leaving directory `/usr/local/pkg/upc/nightly/compiler/bld/gcc' > make[1]: *** [all-gcc] Error 2 > make[1]: Leaving directory `/usr/local/pkg/upc/nightly/compiler/bld' > make: *** [all] Error 2 > > > The g++ version is: g++ (GCC) 3.4.0 > > Currently, install.texi states: > > @heading Tools/packages necessary for building GCC > @table @asis > @item ISO C90 compiler > Necessary to bootstrap GCC, although versions of GCC prior > to 3.4 also allow bootstrapping with a traditional (K&R) C compiler. > > To build all languages in a cross-compiler or other configuration where > 3-stage bootstrap is not performed, you need to start with an existing > GCC binary (version 2.95 or later) because source code for language > frontends other than C might use GCC extensions. > > This appears to be out-of-date with respect to new C++ stage 1 > build requirement. > > Please advise. The code is clearly buggy and should use CONST_CAST - well, or now, finally, const_cast to cast const char * to char *. Richard. > Thanks, > - Gary
Re: [PATCH] Add valgrind support to alloc-pool.c
On Sat, Aug 18, 2012 at 6:17 AM, Andrew Pinski wrote: > Hi, > I implemented this patch almost 6 years ago when the df branch was > being worked on. It adds valgrind support to alloc-pool.c to catch > cases of using memory after free the memory. > > OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions. Ok. Thanks, Richard. > Thanks, > Andrew Pinski > > ChangeLog: > * alloc-pool.c (pool_alloc): Add valgrind markers. > (pool_free): Likewise.
[PATCH v2, rtl-optimization]: Fix PR46829, ICE in spill_failure with -fschedule-insns [was: Fixing instability of -fschedule-insns for x86]
Hello!
After discussion with Oleg, it looks that it is enough to prevent
wrong registers in the output of the (multi-output) insn pattern. As
far as inputs are concerned, combine already handles limited reload
classes in the right way. The problem with x86 is, that reload tried
to fix output operand of the multi-output ins, where scheduler already
moved load of ax register before this insn.
Version 2 of the patch now handles only output operands. Also,
handling of empty constraints was fixed.
2012-08-18 Uros Bizjak
PR rtl-optimization/46829
* combine.c (recog_for_combine): Check operand constraints
to reject instructions where wrong hard registers were propagated
into output operands.
testsuite/ChangeLog:
2012-08-18 Uros Bizjak
PR rtl-optimization/46829
* gcc.target/i386/pr46829.c: New test.
Patch was bootstrapped and regression tested on
x86_64-unknown-linux-gnu {,-m32}.
Uros.
Index: combine.c
===
--- combine.c (revision 190500)
+++ combine.c (working copy)
@@ -10507,6 +10507,7 @@ recog_for_combine (rtx *pnewpat, rtx insn, rtx *pn
int i;
rtx notes = 0;
rtx old_notes, old_pat;
+ int old_icode;
/* If PAT is a PARALLEL, check to see if it contains the CLOBBER
we use to indicate that something didn't match. If we find such a
@@ -10566,6 +10567,7 @@ recog_for_combine (rtx *pnewpat, rtx insn, rtx *pn
print_rtl_single (dump_file, pat);
}
}
+
PATTERN (insn) = old_pat;
REG_NOTES (insn) = old_notes;
@@ -10607,6 +10609,93 @@ recog_for_combine (rtx *pnewpat, rtx insn, rtx *pn
pat = newpat;
}
+ old_pat = PATTERN (insn);
+ old_notes = REG_NOTES (insn);
+ old_icode = INSN_CODE (insn);
+ PATTERN (insn) = pat;
+ REG_NOTES (insn) = notes;
+
+ /* Check operand constraints in case wrong hard registers were
+ propagated into output operands of insn pattern. These invalid
+ insns can eventually confuse reload to error out with a
+ spill failure. See also PR 46829. */
+ if (insn_code_number >= 0
+ && insn_code_number != NOOP_MOVE_INSN_CODE
+ && (INSN_CODE (insn) = recog (PATTERN (insn), insn, 0)) >= 0)
+{
+ extract_insn (insn);
+ preprocess_constraints ();
+
+ for (i = 0; i < recog_data.n_operands; i++)
+ {
+ rtx op;
+ enum machine_mode mode;
+ struct operand_alternative *op_alt;
+ int offset = 0;
+ bool win;
+ int j;
+
+ if (recog_data.operand_type[i] == OP_IN)
+ continue;
+
+ op = recog_data.operand[i];
+ mode = GET_MODE (op);
+
+ /* A unary operator may be accepted by the predicate, but it
+is irrelevant for matching constraints. */
+ if (UNARY_P (op))
+ op = XEXP (op, 0);
+
+ if (GET_CODE (op) == SUBREG)
+ {
+ if (REG_P (SUBREG_REG (op))
+ && REGNO (SUBREG_REG (op)) < FIRST_PSEUDO_REGISTER)
+ offset = subreg_regno_offset (REGNO (SUBREG_REG (op)),
+ GET_MODE (SUBREG_REG (op)),
+ SUBREG_BYTE (op),
+ GET_MODE (op));
+ op = SUBREG_REG (op);
+ }
+
+ if (!(REG_P (op) && HARD_REGISTER_P (op)))
+ continue;
+
+ op_alt = recog_op_alt[i];
+
+ /* Operand has no constraints, anything is OK. */
+ win = !recog_data.n_alternatives;
+
+ for (j = 0; j < recog_data.n_alternatives; j++)
+ {
+ if (op_alt[j].anything_ok
+ || (op_alt[j].matches != -1
+ && reg_fits_class_p (op,
recog_op_alt[op_alt[j].matches][j].cl,
+ offset, mode))
+ || reg_fits_class_p (op, op_alt[j].cl, offset, mode))
+ {
+ win = true;
+ break;
+ }
+ }
+
+ if (!win)
+ {
+ if (dump_file && (dump_flags & TDF_DETAILS))
+ {
+ fputs ("Operand failed to match constraints:\n",
+dump_file);
+ print_rtl_single (dump_file, recog_data.operand[i]);
+ }
+ insn_code_number = -1;
+ break;
+ }
+ }
+}
+
+ PATTERN (insn) = old_pat;
+ REG_NOTES (insn) = old_notes;
+ INSN_CODE (insn) = old_icode;
+
*pnewpat = pat;
*pnotes = notes;
Re: [PATCH] Add working-set size and hotness information to fdo summary (issue6465057)
> +{
> + cs_prg->num = cs_tprg->num;
> + /* Allocate the working set array for the merged summary.
> */
> + if (ws_cnt)
> +{
> + cs_prg->working_set_count = ws_cnt;
> + cs_prg->working_sets = (gcov_ws_info_t *) malloc (
> + ws_cnt * sizeof (gcov_ws_info_t));
> +}
> +}
> + else if (cs_prg->num != cs_tprg->num
> + || ws_cnt != cs_prg->working_set_count)
> +goto read_mismatch;
> + /* Copy over this run's working set information if either this
> is
> + the first run, the total size of the profile (sum_all) is
> much
> + (50%) larger for this run (need to check this before
> updating
> + cs_prg->sum_all below), or this run has a larger working
> + set in the largest (99.99% of sum_all) bucket. */
> + if (ws_cnt
> + && (cs_prg->runs == 1
> + || (cs_tprg->sum_all
> + > (cs_prg->sum_all + cs_prg->sum_all / 2))
> + || (cs_tprg->working_sets[ws_cnt - 1].num_counters
> + > cs_prg->working_sets[ws_cnt - 1].num_counters)))
> +memcpy (cs_prg->working_sets,
> +cs_tprg->working_sets,
> +ws_cnt * sizeof (gcov_ws_info_t));
> cs_prg->sum_all += cs_tprg->sum_all;
Hmm, when you run i.e. gcc bootstrap where the program is run couple hundred
times, this will end up really inaccurate, since it will probably just store
the histogram of insn-attrtab compilation, right?
Why you don't simply write the histogram into gcov file and don't merge the
values
here (i.e. doing the cummulation loop in GCC instead of within libgcov)?
By default you are streaming 128 values that is the same as needed to stream
the histogram.
I suppose we can have environment variable to reduce the histogram size - I
guess in smaller
setups smaller histogram will run just fine...
Honza
Re: [PATCH v2, rtl-optimization]: Fix PR46829, ICE in spill_failure with -fschedule-insns [was: Fixing instability of -fschedule-insns for x86]
On Sat, Aug 18, 2012 at 10:14 AM, Uros Bizjak wrote: > After discussion with Oleg, it looks that it is enough to prevent > wrong registers in the output of the (multi-output) insn pattern. As > far as inputs are concerned, combine already handles limited reload > classes in the right way. The problem with x86 is, that reload tried > to fix output operand of the multi-output ins, where scheduler already > moved load of ax register before this insn. > > Version 2 of the patch now handles only output operands. Also, > handling of empty constraints was fixed. ... but here we fail testcase from PR46843... so we HAVE to check input operands. Uros.
Re: [PATCH][C++] Get rid of TREE_CHAIN use for TREE_VEC (NON_DEFAULT_TEMPLATE_ARGS_COUNT)
Gabriel Dos Reis ha scritto: >C++11 says that an implementation should be able to handle at least >2^10 >template parameters, 2^12 members declared in a single class. Thanks a lot Gaby for pointing out this, I overlooked it. Paolo
Re: [patch] more bitmap obstacks
On Sat, Aug 18, 2012 at 9:01 AM, Tobias Burnus wrote: > Steven Bosscher wrote: >> >> This reduces peak memory usage for the small test case of PR54146 >> Bootstrapped&tested on x86_64-unknown-linux-gnu. OK for trunk? > > > I think it's your patch which breaks bootstrapping here: > > Checking multilib configuration for libgcc... > ... > checking for suffix of object files... configure: error: in > `/projects/tob/gcc-git/gcc-build/x86_64-unknown-linux-gnu/libgcc': > configure: error: cannot compute suffix of object files: cannot compile > > conftest.c: In Function »main«: > conftest.c:7:1: internal compiler error: segmentation fault > } > ^ > > Program received signal SIGSEGV, Segmentation fault. > 0x005bfa40 in bitmap_obstack_free (map=0x18693a0) at > /projects/tob/gcc-git/gcc/gcc/bitmap.c:388 > 388 map->first = (bitmap_element *) map->obstack->heads; > (gdb) p map->obstack > $1 = (bitmap_obstack *) 0x9090909090909090 > > Thus, your patch assumes that malloc returns nullified memory, but e.g. with > MALLOC_PERTURB_ set, that's not the case. If my patch broke this, it was broken before also. I only added a few more bitmap obstacks, but there were lots of existing ones before the patch. Can you file a big report with a test case and instructions to reproduce, so that I can have a look? Ciao! Steven
Re: combine permutations in gimple
Hello,
here is a new patch (passes bootstrap+regtest), which only combines
permutations if the result is the identity. I'll file a PR about more general
combinations to link to this conversation and the cost hook proposition.
Ok?
2012-08-18 Marc Glisse
gcc/
* fold-const.c (fold_ternary_loc): Detect identity permutations.
Canonicalize permutations more.
* tree-ssa-forwprop.c (is_combined_permutation_identity): New function.
(simplify_permutation): Likewise.
(ssa_forward_propagate_and_combine): Call it.
gcc/testsuite/
* gcc.dg/tree-ssa/forwprop-19.c: New testcase.
* gcc.dg/fold-perm.c: Likewise.
--
Marc GlisseIndex: gcc/fold-const.c
===
--- gcc/fold-const.c(revision 190500)
+++ gcc/fold-const.c(working copy)
@@ -14148,58 +14148,96 @@ fold_ternary_loc (location_t loc, enum t
return fold_build2_loc (loc, PLUS_EXPR, type,
const_binop (MULT_EXPR, arg0, arg1), arg2);
if (integer_zerop (arg2))
return fold_build2_loc (loc, MULT_EXPR, type, arg0, arg1);
return fold_fma (loc, type, arg0, arg1, arg2);
case VEC_PERM_EXPR:
if (TREE_CODE (arg2) == VECTOR_CST)
{
- unsigned int nelts = TYPE_VECTOR_SUBPARTS (type), i;
+ unsigned int nelts = TYPE_VECTOR_SUBPARTS (type), i, mask;
unsigned char *sel = XALLOCAVEC (unsigned char, nelts);
tree t;
bool need_mask_canon = false;
+ bool all_in_vec0 = true;
+ bool all_in_vec1 = true;
+ bool maybe_identity = true;
+ bool single_arg = (op0 == op1);
+ bool changed = false;
+ mask = single_arg ? (nelts - 1) : (2 * nelts - 1);
gcc_assert (nelts == VECTOR_CST_NELTS (arg2));
for (i = 0; i < nelts; i++)
{
tree val = VECTOR_CST_ELT (arg2, i);
if (TREE_CODE (val) != INTEGER_CST)
return NULL_TREE;
- sel[i] = TREE_INT_CST_LOW (val) & (2 * nelts - 1);
+ sel[i] = TREE_INT_CST_LOW (val) & mask;
if (TREE_INT_CST_HIGH (val)
|| ((unsigned HOST_WIDE_INT)
TREE_INT_CST_LOW (val) != sel[i]))
need_mask_canon = true;
+
+ if (sel[i] < nelts)
+ all_in_vec1 = false;
+ else
+ all_in_vec0 = false;
+
+ if ((sel[i] & (nelts-1)) != i)
+ maybe_identity = false;
+ }
+
+ if (maybe_identity)
+ {
+ if (all_in_vec0)
+ return op0;
+ if (all_in_vec1)
+ return op1;
}
if ((TREE_CODE (arg0) == VECTOR_CST
|| TREE_CODE (arg0) == CONSTRUCTOR)
&& (TREE_CODE (arg1) == VECTOR_CST
|| TREE_CODE (arg1) == CONSTRUCTOR))
{
t = fold_vec_perm (type, arg0, arg1, sel);
if (t != NULL_TREE)
return t;
}
+ if (all_in_vec0)
+ op1 = op0;
+ else if (all_in_vec1)
+ {
+ op0 = op1;
+ for (i = 0; i < nelts; i++)
+ sel[i] -= nelts;
+ need_mask_canon = true;
+ }
+
+ if (op0 == op1 && !single_arg)
+ changed = true;
+
if (need_mask_canon && arg2 == op2)
{
tree *tsel = XALLOCAVEC (tree, nelts);
tree eltype = TREE_TYPE (TREE_TYPE (arg2));
for (i = 0; i < nelts; i++)
tsel[i] = build_int_cst (eltype, sel[i]);
- t = build_vector (TREE_TYPE (arg2), tsel);
- return build3_loc (loc, VEC_PERM_EXPR, type, op0, op1, t);
+ op2 = build_vector (TREE_TYPE (arg2), tsel);
+ changed = true;
}
+
+ if (changed)
+ return build3_loc (loc, VEC_PERM_EXPR, type, op0, op1, op2);
}
return NULL_TREE;
default:
return NULL_TREE;
} /* switch (code) */
}
/* Perform constant folding and related simplification of EXPR.
The related simplifications include x*1 => x, x*0 => 0, etc.,
Index: gcc/tree-ssa-forwprop.c
===
--- gcc/tree-ssa-forwprop.c (revision 190500)
+++ gcc/tree-ssa-forwprop.c (working copy)
@@ -2570,20 +2570,109 @@ combine_conversions (gimple_stmt_iterato
gimple_assign_set_rhs_code (stmt, CONVERT_EXPR);
update_stmt (stmt);
return remove_prop_source_from_use (op0) ? 2 : 1;
}
}
}
return 0;
}
+/* Determine whether applying the 2 permutations (mask1 then mask2)
+ gives back one of the input. */
+
+static int
+is_combined_permutation_identity (tree mask1, tree mask2)
+{
+ tree mask;
+ unsigned int nelts, i, j;
+ bool maybe_identity1 = true;
+ bool
Re: [patch] more bitmap obstacks
Steven Bosscher wrote: On Sat, Aug 18, 2012 at 9:01 AM, Tobias Burnus wrote: I think it's your patch which breaks bootstrapping here: Program received signal SIGSEGV, Segmentation fault. 0x005bfa40 in bitmap_obstack_free (map=0x18693a0) at /projects/tob/gcc-git/gcc/gcc/bitmap.c:388 388 map->first = (bitmap_element *) map->obstack->heads; (gdb) p map->obstack $1 = (bitmap_obstack *) 0x9090909090909090 Thus, your patch assumes that malloc returns nullified memory, but e.g. with MALLOC_PERTURB_ set, that's not the case. If my patch broke this, it was broken before also. I only added a few more bitmap obstacks, but there were lots of existing ones before the patch. Maybe, but MALLOC_PERTURB_ builds were successful since years – including my Friday morning build (though, I didn't do a bootstrap). My last full bootstrap was on 2012-08-15 and a FreeBSD jemalloc's junk filling build was done by Steve on the 10th. Thus, either there is a fairly new bug or some change made an old bug surface. I also haven't bisected, thus it could also be some other patch. Can you file a big report with a test case and instructions to reproduce, so that I can have a look? I filled a small bug report at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54313 I hope it is sufficient. If you need more, please tell me. Tobias
Re: [patch] more bitmap obstacks
On Sat, Aug 18, 2012 at 12:21 PM, Tobias Burnus wrote: > I filled a small bug report at > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54313 Yup, thanks. * dse.c (dse_step7): Don't free kill_on_calls bitmap, it is freed when its obstack is release. Index: dse.c === --- dse.c (revision 190475) +++ dse.c (working copy) @@ -3823,7 +3823,6 @@ dse_step7 (void) VEC_free (group_info_t, heap, rtx_group_vec); BITMAP_FREE (all_blocks); BITMAP_FREE (scratch); - BITMAP_FREE (kill_on_calls); free_alloc_pool (rtx_store_info_pool); free_alloc_pool (read_info_pool);
Re: [patch] more bitmap obstacks
On Sat, Aug 18, 2012 at 12:28 PM, Steven Bosscher wrote: > On Sat, Aug 18, 2012 at 12:21 PM, Tobias Burnus wrote: >> I filled a small bug report at >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54313 > > Yup, thanks. > > * dse.c (dse_step7): Don't free kill_on_calls bitmap, it is > freed when its obstack is release. Looks obvious. > Index: dse.c > === > --- dse.c (revision 190475) > +++ dse.c (working copy) > @@ -3823,7 +3823,6 @@ dse_step7 (void) >VEC_free (group_info_t, heap, rtx_group_vec); >BITMAP_FREE (all_blocks); >BITMAP_FREE (scratch); > - BITMAP_FREE (kill_on_calls); > >free_alloc_pool (rtx_store_info_pool); >free_alloc_pool (read_info_pool);
Re: [patch] more bitmap obstacks
On Sat, Aug 18, 2012 at 12:39 PM, Richard Guenther wrote: > On Sat, Aug 18, 2012 at 12:28 PM, Steven Bosscher > wrote: >> On Sat, Aug 18, 2012 at 12:21 PM, Tobias Burnus wrote: >>> I filled a small bug report at >>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54313 >> >> Yup, thanks. >> >> * dse.c (dse_step7): Don't free kill_on_calls bitmap, it is >> freed when its obstack is release. > > Looks obvious. Yes, I already committed it.
Re: Always define USE_PT_GNU_EH_FRAME in crtstuff.c for glibc
On Sat, 18 Aug 2012, Ian Lance Taylor wrote: > Looking at the #if just before this one, it looks like you've omitted > the checks for a version of glibc before 2.2.2. Also I'm not sure how > this will play out with uClibc: it seems like it might always turn on > USE_PT_GNU_EH_FRAME, which might or might not be OK. > > These would not be issues if you added && defined(inhibit_libc). Did > you consider that? Here is a version with the extra defined(inhibit_libc) test. It's passed the same tests as before on arm-none-linux-gnueabi and x86_64-unknown-linux-gnu. OK to commit? 2012-08-18 Joseph Myers * crtstuff.c (USE_PT_GNU_EH_FRAME): Define for systems using glibc even if inhibit_libc. Index: libgcc/crtstuff.c === --- libgcc/crtstuff.c (revision 190491) +++ libgcc/crtstuff.c (working copy) @@ -1,7 +1,7 @@ /* Specialized bits of code needed to support construction and destruction of file-scope objects in C++ code. Copyright (C) 1991, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001 - 2002, 2003, 2004, 2005, 2006, 2007, 2009, 2010, 2011 + 2002, 2003, 2004, 2005, 2006, 2007, 2009, 2010, 2011, 2012 Free Software Foundation, Inc. Contributed by Ron Guilmette (r...@monkeys.com). @@ -113,6 +113,20 @@ # define USE_PT_GNU_EH_FRAME # endif #endif + +#if defined(OBJECT_FORMAT_ELF) \ +&& !defined(OBJECT_FORMAT_FLAT) \ +&& defined(HAVE_LD_EH_FRAME_HDR) \ +&& !defined(CRTSTUFFT_O) \ +&& defined(inhibit_libc) \ +&& (defined(__GLIBC__) || defined(__gnu_linux__) || defined(__GNU__)) +/* On systems using glibc, an inhibit_libc build of libgcc is only + part of a bootstrap process. Build the same crt*.o as would be + built with headers present, so that it is not necessary to build + glibc more than once for the bootstrap to converge. */ +# define USE_PT_GNU_EH_FRAME +#endif + #if defined(EH_FRAME_SECTION_NAME) && !defined(USE_PT_GNU_EH_FRAME) # define USE_EH_FRAME_REGISTRY #endif -- Joseph S. Myers jos...@codesourcery.com
Re: [patch] speed up ifcvt:cond_move_convert_if_block
On Thu, Aug 16, 2012 at 12:06 PM, Richard Guenther wrote: > On Thu, Aug 16, 2012 at 1:11 AM, Steven Bosscher > wrote: >> On Mon, Aug 6, 2012 at 1:27 PM, Paolo Bonzini wrote: 2. sparseset has the same problem of memory clearing (for valgrind, see sparseset_alloc). >>> >>> ... only the sparse array needs this clearing, but currently we do it >>> for both. >> >> And according to the fat comment before the xcalloc, it's not even >> really needed. Why can't we just tell valgrind to treat the memory as >> defined, like in this patchlet: > > Indeed ... I suppose ok if it bootstraps / tests w/o valgrind checking and > if a cc1 builds with valgrind checking. Here's what I'll commit: Index: sparseset.c === --- sparseset.c (revision 190474) +++ sparseset.c (working copy) @@ -30,12 +30,14 @@ unsigned int n_bytes = sizeof (struct sparseset_def) + ((n_elms - 1) * 2 * sizeof (SPARSESET_ELT_TYPE)); - /* We use xcalloc rather than xmalloc to silence some valgrind uninitialized + sparseset set = XNEWVAR(struct sparseset_def, n_bytes); + + /* Mark the sparseset as defined to silence some valgrind uninitialized read errors when accessing set->sparse[n] when "n" is not, and never has been, in the set. These uninitialized reads are expected, by design and - harmless. If this turns into a performance problem due to some future - additional users of sparseset, we can revisit this decision. */ - sparseset set = (sparseset) xcalloc (1, n_bytes); + harmless. */ + VALGRIND_DISCARD (VALGRIND_MAKE_MEM_DEFINED (set, n_bytes)); + set->dense = &(set->elms[0]); set->sparse = &(set->elms[n_elms]); set->size = n_elms;
Speedups/Cleanups: End of GSOC patch collection
Hello list, for the following couple of days I'll be posting under this thread my collection of patches. Unless otherwise mentioned they've been bootstrapped and tested on x86, but with a three-weeks old snapshot, that is pre-C++ conversion. I plan to test again next week with a latest snapshot, so please wait for it before applying. Most things are minor changes and tweaks, some are ported patches from last year, some are new. I also have some bigger patches that are flawed (some don't even compile) either because of difficulties I encountered or simply lack of time. I 'll try and post what is presentable from them, I'd appreciate discussion on whether/how to continue with those. Thanks, Dimitris
Re: Inheritance of gfc_symbol / gfc_component
On 17/08/2012 23:32, Tobias Schlüter wrote: > > Following up on myself: > > On 2012-08-16 14:59, Tobias Schlüter wrote: >> A place where C++ inheritance is a trivial improvement is the red-black >> tree used for storing various objects (gfc_symtree, gfc_gsymbol, >> gfc_st_label, I think). This is currently implemented with macro-based >> inheritance. It is trivial to replace the macro with C++ inheritance, > > So I have a patch for this which passes the testsuite, but I'm not sure > if it's valid C++ [...] > The problem is that the initialization of format_asterisk is not allowed > in the C++ standard > So it's not valid ;-) > I thought I could work around this problem without introducing a > constructor by: > 1) using 0 instead of -1 as value for this fake label (which is also >not a valid value for a label, so it can't collide > 2) setting ST_LABEL_FORMAT = 0 > and then > 3) not initializing at all, assuming that as for a C struct >format_asterisk would end up in .bss and thus be zero initialized. > I would use a constructor. > That said, I had to introduce lots of type-casts in the patch, because I > didn't want to work with templates, I don't like templates as it looks ugly in the code, but I think that in this case it is the proper way to represent a bbt: the bbt is a way to access the data, not part of the data itself. By the way, I'm not sure the bbt has any value over the STL's map. > while using typesafe interfaces > wherever possible, so the functionally equivalent code actually became > insignificantly larger with C++ replacing macro-based inheritance. > The bbt is a well separated part of the frontend with a small set of well defined "methods" working on it. As a result of this, it is easy to change it's internal implementation or the way it is accessed; as long as the interfaces remain the same, any change to it would be basically "insignificant". To put the story short, I don't think the bbt is that important (which doesn't mean I'm opposed to any change). On the other hand, If we go the inheritance way, I think that we could save some code by moving manual bbt walking functions from symbol.c and module.c into member functions (i.e. start doing some real cleanup). Could you post the not-yet-finished patch? Mikael
Re: Speedups/Cleanups: End of GSOC patch collection
2012-08-18 Dimitrios Apostolou
* dwarf2out.c (output_indirect_string): Use
ASM_OUTPUT_INTERNAL_LABEL instead of slower ASM_OUTPUT_LABEL.
* varasm.c (assemble_string): Don't break string in chunks, this
is assembler specific and already done in most versions of
ASM_OUTPUT_ASCII.
I think there is no correctness issue regarding output_indirect_string()
since .debug_str are always compiler generated labels, and this gives a
small speedup with -g3 debug info.
And regarding assemble_string() I find it superfluous to break it in two
places. I found only the following versions of ASM_OUTPUT_ASCII not caring
about string length, I guess the assemblers don't have a limit:
arm.c: vmsdbgout.c:ASM_OUTPUT_ASCII
picochip.c: picochip_output_ascii()
pdp11.c: output_ascii()
Thanks,
Dimitris=== modified file 'gcc/varasm.c'
--- gcc/varasm.c2012-08-15 01:56:07 +
+++ gcc/varasm.c2012-08-16 06:12:28 +
@@ -1726,22 +1726,7 @@ assemble_align (int align)
void
assemble_string (const char *p, int size)
{
- int pos = 0;
- int maximum = 2000;
-
- /* If the string is very long, split it up. */
-
- while (pos < size)
-{
- int thissize = size - pos;
- if (thissize > maximum)
- thissize = maximum;
-
- ASM_OUTPUT_ASCII (asm_out_file, p, thissize);
-
- pos += thissize;
- p += thissize;
-}
+ ASM_OUTPUT_ASCII (asm_out_file, p, size);
}
=== modified file 'gcc/dwarf2out.c'
--- gcc/dwarf2out.c 2012-08-15 01:56:07 +
+++ gcc/dwarf2out.c 2012-08-16 06:19:19 +
@@ -20887,7 +20887,7 @@ output_indirect_string (void **h, void *
if (node->form == DW_FORM_strp)
{
switch_to_section (debug_str_section);
- ASM_OUTPUT_LABEL (asm_out_file, node->label);
+ ASM_OUTPUT_INTERNAL_LABEL (asm_out_file, node->label);
assemble_string (node->str, strlen (node->str) + 1);
}
Re: PATCH: Add x32 support to config.guess
On Thu, Aug 16, 2012 at 10:26:48AM -0700, H.J. Lu wrote: > GCC on Linux/x86-64 may be configured for x32: > https://sites.google.com/site/x32abi/ > by default and the Linux/x32 target should be x86_64-VENDOR-linux-gnux32. > This patch adds x32 support to config.guess. OK to install? > + eval $set_cc_for_build I am working to eliminate the use of $set_cc_for_build and am not really willing to accept any new patches which make this further entrenched. Can you please find another way? Thanks, Ben signature.asc Description: Digital signature
Re: CXX conversion: min g++ version pre-requisite?
On Fri, Aug 17, 2012 at 9:51 PM, Richard Guenther wrote: > On Sat, Aug 18, 2012 at 3:36 AM, Gary Funck wrote: >> >> Paul Hargrove noted the following build failure on >> an older x86-32 Linux (Redhat 8.0) system. >> >> g++ -c -g -O2 -DIN_GCC -fno-exceptions -fno-rtti -W -Wall >> -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -fno-common >> -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild >> -I/usr/local/pkg/upc/nightly/compiler/gupc-src/gcc >> -I/usr/local/pkg/upc/nightly/compiler/gupc-src/gcc/build >> -I/usr/local/pkg/upc/nightly/compiler/gupc-src/gcc/../include >> -I/usr/local/pkg/upc/nightly/compiler/gupc-src/gcc/../libcpp/include >> -I/usr/local/pkg/gmp-4.2.4/include -I/usr/local/pkg/mpfr-2.4.2/include >> -I/usr/local/pkg/mpc-0.8/include >> -I/usr/local/pkg/upc/nightly/compiler/gupc-src/gcc/../libdecnumber >> -I/usr/local/pkg/upc/nightly/compiler/gupc-src/gcc/../libdecnumber/bid >> -I../libdecnumber\ >> -o build/genoutput.o >> /usr/local/pkg/upc/nightly/compiler/gupc-src/gcc/genoutput.c >> /usr/local/pkg/upc/nightly/compiler/gupc-src/gcc/genoutput.c: In function >> `void note_constraint(rtx_def*, int)': >> /usr/local/pkg/upc/nightly/compiler/gupc-src/gcc/genoutput.c:1178: error: >> reinterpret_cast from type `const char (*)[1]' to type `char*' casts away >> constness >> make[2]: *** [build/genoutput.o] Error 1 >> make[2]: Leaving directory `/usr/local/pkg/upc/nightly/compiler/bld/gcc' >> make[1]: *** [all-gcc] Error 2 >> make[1]: Leaving directory `/usr/local/pkg/upc/nightly/compiler/bld' >> make: *** [all] Error 2 >> >> >> The g++ version is: g++ (GCC) 3.4.0 >> >> Currently, install.texi states: >> >> @heading Tools/packages necessary for building GCC >> @table @asis >> @item ISO C90 compiler >> Necessary to bootstrap GCC, although versions of GCC prior >> to 3.4 also allow bootstrapping with a traditional (K&R) C compiler. >> >> To build all languages in a cross-compiler or other configuration where >> 3-stage bootstrap is not performed, you need to start with an existing >> GCC binary (version 2.95 or later) because source code for language >> frontends other than C might use GCC extensions. >> >> This appears to be out-of-date with respect to new C++ stage 1 >> build requirement. >> >> Please advise. > > The code is clearly buggy and should use CONST_CAST - well, or now, > finally, const_cast to cast const char * to char *. > > Richard. > >> Thanks, >> - Gary Why do newer compilers not error out?
Re: PATCH: Add x32 support to config.guess
On Sat, Aug 18, 2012 at 5:49 AM, Ben Elliston wrote: > On Thu, Aug 16, 2012 at 10:26:48AM -0700, H.J. Lu wrote: > >> GCC on Linux/x86-64 may be configured for x32: >> https://sites.google.com/site/x32abi/ >> by default and the Linux/x32 target should be x86_64-VENDOR-linux-gnux32. >> This patch adds x32 support to config.guess. OK to install? > >> + eval $set_cc_for_build > > I am working to eliminate the use of $set_cc_for_build and am not > really willing to accept any new patches which make this further > entrenched. Can you please find another way? > In case of x32, the only difference between x32 and x86-64 is the default output of CC. What do you recommend how to detect x32? Thanks. -- H.J.
Re: [PATCH v2, rtl-optimization]: Fix PR46829, ICE in spill_failure with -fschedule-insns [was: Fixing instability of -fschedule-insns for x86]
On Sat, Aug 18, 2012 at 1:23 AM, Uros Bizjak wrote: > On Sat, Aug 18, 2012 at 10:14 AM, Uros Bizjak wrote: > >> After discussion with Oleg, it looks that it is enough to prevent >> wrong registers in the output of the (multi-output) insn pattern. As >> far as inputs are concerned, combine already handles limited reload >> classes in the right way. The problem with x86 is, that reload tried >> to fix output operand of the multi-output ins, where scheduler already >> moved load of ax register before this insn. >> >> Version 2 of the patch now handles only output operands. Also, >> handling of empty constraints was fixed. > > ... but here we fail testcase from PR46843... so we HAVE to check > input operands. > If this is very critical, can you add a target hook to decide whether to check input/output operands? -- H.J.
[PATCH][C++] Fix constant reference in a lambda (PR c++/53488)
Hello, I've been investigating a bug in gcc I came across recently and after some difficulties, I have produced a patch that actually fixes that behavior. However, I don't think the patch is very good and I would really appreciate your help in making it better. The problem is that when a const(expr) variable is used in a lambda, it yields garbage values in gcc when the initializer is dependent. Moreover, it should not be captured if it fulfills the requirements of a constant expression (at least that's how I understand the definition of "odr-used" along with the definition of default captures). finish_id_expression did return VAR_DECL for the corresponding automatic variable in that case, but didn't create the capture. The idea of the fix is to postpone the decision whether or not to capture later to the template instantiation. This is because until then, we cannot know if the variable fulfills the conditions for a constant expression or not. So the patch assumes that if the constant value is a VAR_DECL (which is what I've found to happen in the debugger, although I'm not sure this is the only case) and we are in a template declaration, it just leaves the id expression there as is. Then the patch fiddles with the capture list in template instantiation code. Because new captures can be added while processing the template, we need to concatenate them with the original list from the template, plus there's a small hack to avoid producing the lambda-to-function-pointer conversion operator while we still don't have the final capture list. I have produced two tests (in the patch) and ran the testsuite in the gcc subdirectory successfully. I've also tested the behavior on a testcase in the attached test.cpp file (it should print ok with all possible combinations of #defined macros). I'd be grateful on your comments on this, especially - whether the approach taken is a good one, and - whether my assumptions about what's going on in the code (expressed either in this mail and in the comments in code) are true Regards Jiri Palecek gcc.diff Description: Binary data test.cpp Description: Binary data
Re: [rtl, i386] combine concat+permutation
On Fri, 17 Aug 2012, Jakub Jelinek wrote: On Fri, Aug 03, 2012 at 10:47:25PM +0200, Marc Glisse wrote: Hello, this is a follow up to the patch applied after this discussion: http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00504.html It handles the -mavx __builtin_shuffle case mentioned there. It passes bootstrap (languages=c,c++) and regtest on x86_64. Ok. Thanks. 2012-08-04 Marc Glisse gcc/ * simplify-rtx.c (simplify_binary_operation_1): Optimize shuffle of a concatenation. gcc/testsuite/ * gcc.target/i386/perm-concat.c: New test. Thanks, committed. I just noticed that for __builtin_shuffle, this is an optimization that fold_ternary knows, but which never happens for 2 reasons: 1) the first time it sees the VEC_PERM_EXPR, the last argument is a CONSTRUCTOR but it only handles VECTOR_CST (this also breaks constexpr in C++11) 2) arg0 and arg1 are ssa names, not directly constructors, and there is no combine pass. fold_ternary does get called quite a few times on it, so I tried cheating in gdb and replacing the ssa names by the constructors, and it did fold as expected, but the optimization was then discarded because valid_gimple_rhs_p doesn't like constructors. I guess I'll have to add it to forwprop (it can make sense to restrict it to the case where the constructor is only used once, since shuffles might be faster than constructions). -- Marc Glisse
Re: Speedups/Cleanups: End of GSOC patch collection
Hi, these are the type-safe obstack macros that I use in other patches. As
requested, I also changed XOBFINISH to return (T *) and changed all
callers, felt a little strange to change (char *) to char. I also replaced
all _obstack_begin() calls in libcpp with obstack_init() which is the
documented way of allocating macros.
2012-08-18 Dimitrios Apostolou
* include/libiberty.h (XOBDELETE, XOBGROW, XOBGROWVEC, XOBSHRINK)
(XOBSHRINKVEC, XOBFINISH): New type-safe macros for obstack
operations.
(XOBFINISH): Changed to return (T *) instead of T. All callers
updated.
* libcpp/include/symtab.h (obstack_chunk_alloc)
(obstack_chunk_free): Define, so that obstack_init() can be used.
* libcpp/internal.h (struct cset_converter): Same.
* libcpp/files.c (_cpp_init_files): Changed _obstack_begin() to
obstack_init().
* libcpp/identifiers.c (_cpp_init_hashtable): Same.
* libcpp/symtab.c (ht_create): Same.
* libcpp/init.c (cpp_create_reader): Same.
Thanks,
Dimitris
2012-08-18 Dimitrios Apostolou
* include/libiberty.h (XOBDELETE, XOBGROW, XOBGROWVEC, XOBSHRINK)
(XOBSHRINKVEC, XOBFINISH): New type-safe macros for obstack
operations.
(XOBFINISH): Changed to return (T *) instead of T. All callers
updated.
* libcpp/include/symtab.h (obstack_chunk_alloc)
(obstack_chunk_free): Define, so that obstack_init() can be used.
* libcpp/internal.h (struct cset_converter): Same.
* libcpp/files.c (_cpp_init_files): Changed _obstack_begin() to
obstack_init().
* libcpp/identifiers.c (_cpp_init_hashtable): Same.
* libcpp/symtab.c (ht_create): Same.
* libcpp/init.c (cpp_create_reader): Same.
=== modified file 'gcc/c-family/c-lex.c'
--- gcc/c-family/c-lex.c2012-06-19 19:55:33 +
+++ gcc/c-family/c-lex.c2012-08-18 13:42:37 +
@@ -1037,7 +1037,7 @@ lex_string (const cpp_token *tok, tree *
/* We have read one more token than we want. */
_cpp_backup_tokens (parse_in, 1);
if (concats)
-strs = XOBFINISH (&str_ob, cpp_string *);
+strs = XOBFINISH (&str_ob, cpp_string);
if (concats && !objc_string && !in_system_header)
warning (OPT_Wtraditional,
=== modified file 'gcc/collect2.c'
--- gcc/collect2.c 2012-05-31 20:19:00 +
+++ gcc/collect2.c 2012-08-18 13:42:51 +
@@ -514,7 +514,7 @@ extract_string (const char **pp)
obstack_1grow (&temporary_obstack, '\0');
*pp = p;
- return XOBFINISH (&temporary_obstack, char *);
+ return XOBFINISH (&temporary_obstack, char);
}
void
@@ -535,7 +535,7 @@ dump_ld_file (const char *name, FILE *to
const char *word, *p;
char *result;
obstack_1grow (&temporary_obstack, '\0');
- word = XOBFINISH (&temporary_obstack, const char *);
+ word = XOBFINISH (&temporary_obstack, const char);
if (*word == '.')
++word, putc ('.', to);
@@ -943,7 +943,7 @@ maybe_run_lto_and_relink (char **lto_ld_
lto_o_files = XNEWVEC (char *, num_files + 1);
lto_o_files[num_files] = NULL;
- start = XOBFINISH (&temporary_obstack, char *);
+ start = XOBFINISH (&temporary_obstack, char);
for (i = 0; i < num_files; ++i)
{
end = start;
=== modified file 'gcc/dbxout.c'
--- gcc/dbxout.c2012-06-24 17:58:46 +
+++ gcc/dbxout.c2012-08-18 13:48:19 +
@@ -864,7 +864,7 @@ dbxout_finish_complex_stabs (tree sym, s
obstack_1grow (&stabstr_ob, '\0');
len = obstack_object_size (&stabstr_ob);
- chunk = str = XOBFINISH (&stabstr_ob, char *);
+ chunk = str = XOBFINISH (&stabstr_ob, char);
/* Within the buffer are a sequence of NUL-separated strings,
each of which is to be written out as a separate stab
@@ -897,7 +897,7 @@ dbxout_finish_complex_stabs (tree sym, s
comma than to do a two-character fputs. */
obstack_grow (&stabstr_ob, "\",", 2);
len = obstack_object_size (&stabstr_ob);
- str = XOBFINISH (&stabstr_ob, char *);
+ str = XOBFINISH (&stabstr_ob, char);
fwrite (str, 1, len, asm_out_file);
DBX_FINISH_STABS (sym, code, line, addr, label, number);
=== modified file 'gcc/gcc.c'
--- gcc/gcc.c 2012-08-15 01:56:07 +
+++ gcc/gcc.c 2012-08-18 13:47:06 +
@@ -1435,7 +1435,7 @@ init_spec (void)
}
obstack_1grow (&obstack, '\0');
-libgcc_spec = XOBFINISH (&obstack, const char *);
+libgcc_spec = XOBFINISH (&obstack, const char);
}
#endif
#ifdef USE_AS_TRADITIONAL_FORMAT
@@ -1444,7 +1444,7 @@ init_spec (void)
static const char tf[] = "--traditional-format ";
obstack_grow (&obstack, tf, sizeof(tf) - 1);
obstack_grow0 (&obstack, asm_spec, strlen (asm_spec));
-asm_spec = XOBFINISH (&obstack, const char *);
+asm_spec = XOBFINISH (&obstack, const char);
}
#endif
@@ -1469,7 +1469,
Re: CXX conversion: min g++ version pre-requisite?
On 08/18/12 09:51:43, Richard Guenther wrote: > The code is clearly buggy and should use CONST_CAST - well, or now, > finally, const_cast to cast const char * to char *. It is interesting that an old version of g++ caught this but a newer version didn't? - Gary
Re: Always define USE_PT_GNU_EH_FRAME in crtstuff.c for glibc
On Sat, Aug 18, 2012 at 3:50 AM, Joseph S. Myers wrote: > > 2012-08-18 Joseph Myers > > * crtstuff.c (USE_PT_GNU_EH_FRAME): Define for systems using glibc > even if inhibit_libc. This is OK. Thanks. Ian
Re: Inheritance of gfc_symbol / gfc_component
Dear Mikael,
On 2012-08-18 13:41, Mikael Morin wrote:
On 17/08/2012 23:32, Tobias Schlüter wrote:
The problem is that the initialization of format_asterisk is not allowed
in the C++ standard
So it's not valid ;-)
Sure, that's why I tried to work around it. My question was: is the
workaround valid?
I thought I could work around this problem without introducing a
constructor by:
1) using 0 instead of -1 as value for this fake label (which is also
not a valid value for a label, so it can't collide
2) setting ST_LABEL_FORMAT = 0
and then
3) not initializing at all, assuming that as for a C struct
format_asterisk would end up in .bss and thus be zero initialized.
I would use a constructor.
Which would defeat the purpose of this patch: simpler code (no macro
magic) + more typesafety. A constructor which is needed for a single
case is no simplification IMO.
That said, I had to introduce lots of type-casts in the patch, because I
didn't want to work with templates,
I don't like templates as it looks ugly in the code, but I think that in
this case it is the proper way to represent a bbt: the bbt is a way to
access the data, not part of the data itself. By the way, I'm not sure
the bbt has any value over the STL's map.
No templates are allowed by the coding standard. The benefit over the
STL's map or a hashtable (which is better suited) is that we can
traverse a tree in defined order. We use this property to write
reproducible module files. But sure, a bigger plan would be to move to
the compiler's hashtable code, if one introduced ordering in the places
where we care about it.
while using typesafe interfaces
wherever possible, so the functionally equivalent code actually became
insignificantly larger with C++ replacing macro-based inheritance.
The bbt is a well separated part of the frontend with a small set of
well defined "methods" working on it. As a result of this, it is easy
to change it's internal implementation or the way it is accessed; as
long as the interfaces remain the same, any change to it would be
basically "insignificant". To put the story short, I don't think the
bbt is that important (which doesn't mean I'm opposed to any change).
Sure, I had hoped it would be a non-invasive change, which due to the
constructor issue, it didn't turn out to be. Note that I need all of
these typecasts because I decided to make the interfaces of the various
recursive functions use the specific types in their prototypes, I
thought this was clearer than the other possibility of using gfc_bbt in
the prototypes and then casting to the specific type when the pointer's
properties are accessed. That way the type wouldn't be exposed in the
function prototype.
On the other hand, If we go the inheritance way, I think that we could
save some code by moving manual bbt walking functions from symbol.c and
module.c into member functions (i.e. start doing some real cleanup).
Could you post the not-yet-finished patch?
Please find it attached. Note that two void* remain:
gfc_{insert|delete}_bbt still need it, and I don't think there's a way
around this without templates and without significantly changing the
code. As I said before, I think a change needs to have a benefit. I'm
disappointed by this outcome, but think this patch fails this
requirement mainly because of the format_asterisk issue.
(In the process I added const to the comparator function, which added a
few more diffs I wouldn't have needed otherwise.)
Cheers,
- Tobi
2012-08-18 Tobias Schlüter
* gfortran.h (gfc_sl_type): Set ST_LABEL_FORMAT to 0.
(BBT_HEADER): Remove. Replace with ...
(gfc_bbt): ... new type.
(gfc_st_label): Inherit from gfc_bbt instead of macro magic.
Use C++ declaration syntax.
(gfc_symtree): Likewise.
(gfc_symbol): Likewise.
(compare_fn): Replace void* with typed pointer.
(gfc_insert_bbt): Likewise.
(gfc_delete_bbt): Likewise.
* bbt.c (gfc_bbt): Remove.
(gfc_insert_bbt): Use typed pointer.
(gfc_delete_bbt): Likewise.
* class.c (add_procs_to_declared_vtabl): Add typecasts.
* dump-parse-tree.c (traverse_uop): Same.
* interface.c (find_symtree0): Same.
* io.c (format_asterisk): Remove initializer.
* module.c (pointer_info): Inherit from gfc_bbt. Use C++
declaration syntax.
(free_pi_tree): Add typecasts.
(compare_pointers): Change arguments to const gfc_bbt*, adapt casts.
(compare_integers): Same.
(find_pointer): Add typecasts.
(get_integer): Same.
(fp2): Same.
(true_name): Inherit from gfc_bbt. Use C++ declaration syntax.
(compare_true_names): Change arguments to const gfc_bbt*, adapt
casts.
(build_tnt): Add typecasts.
(free_true_name): Same.
(find_symtree_for_symbol): Same.
(find_symbol): Same.
(load_needed):
Re: PATCH: Add x32 support to config.guess
On Aug 18, 2012, at 6:52 AM, "H.J. Lu" wrote: > In case of x32, the only difference between x32 and x86-64 is > the default output of CC. What do you recommend how to > detect x32? So, is there a cpp symbol that is defined for code-gen? If so, something like If [ $(gcc -x c /dev/null -dM -E | grep x32) = x32 ]; then fi Would do it.
Re: PATCH: Add x32 support to config.guess
On Saturday 18 August 2012 13:32:59 Mike Stump wrote: > On Aug 18, 2012, at 6:52 AM, "H.J. Lu" wrote: > > In case of x32, the only difference between x32 and x86-64 is > > the default output of CC. What do you recommend how to > > detect x32? > > So, is there a cpp symbol that is defined for code-gen? If so, something > like > > If [ $(gcc -x c /dev/null -dM -E | grep x32) = x32 ]; then fi > > Would do it. how is executing `gcc` any better than $CC_FOR_BUILD ? your code suggestion here is pretty much what H.J. Lu is already doing. -mike signature.asc Description: This is a digitally signed message part.
Re: PATCH: Add x32 support to config.guess
On Sat, Aug 18, 2012 at 10:40 AM, Mike Frysinger wrote: > On Saturday 18 August 2012 13:32:59 Mike Stump wrote: >> On Aug 18, 2012, at 6:52 AM, "H.J. Lu" wrote: >> > In case of x32, the only difference between x32 and x86-64 is >> > the default output of CC. What do you recommend how to >> > detect x32? >> >> So, is there a cpp symbol that is defined for code-gen? If so, something >> like >> >> If [ $(gcc -x c /dev/null -dM -E | grep x32) = x32 ]; then fi >> >> Would do it. > > how is executing `gcc` any better than $CC_FOR_BUILD ? > > your code suggestion here is pretty much what H.J. Lu is already doing. > -mike There are 12 existing set_cc_for_build usages in config.guess. I don't think it is reasonable to require x32 not to use it without providing an alternative. If you want to remove set_cc_for_build, one extra usage doesn't make it much harder to do. -- H.J.
[graphds.h] Allocate graph from obstack
Initially I had one obstack per struct graph, which was better than using
XNEW for every edge, but still obstack_init() called from new_graph() was
too frequent.
So in this iteration of the patch the obstack is static global,
initialised once and never freed. Please advise on whether this is
acceptable, and also where I should initialise the obstack once, and avoid
checking if it's NULL in every use.
Minor speed gains (couple of ms), tested with pre-C++ conversion snapshot,
I'll retest soon and post update.
Thanks,
Dimitris
2012-08-18 Dimitrios Apostolou
* gcc/graphds.h: Guarded the header file. Included libiberty.h and
obstack.h.
(graph_obstack): New static obstack to allocate graphs and
graph_edges from.
(new_graph, add_edge): Add obstack argument.
(free_graph): Remove.
* gcc/graphds.c (new_graph): Allocate graph, vertices from obstack.
(add_edge): Allocate edge from obstack.
(free_graph): Remove, all graph data is now freed when freeing the
object in the obstack.
* gcc/tree-data-ref.h (free_rdg): Same.
(build_empty_rdg): Add obstack argument.
* gcc/cfgloopanal.c (mark_irreducible_loops): Initialise obstack
if it's not, use it for graph allocations.
* gcc/dominance.c (iterate_fix_dominators): Same.
* gcc/graphite-sese-to-poly.c (build_alias_set_optimal_p)
(build_base_obj_set_for_drs): Same.
* gcc/tree-data-ref.c (rdg_vertex_for_stmt)
(create_rdg_edge_for_ddr, create_rdg_edges_for_scalar)
(create_rdg_edges, create_rdg_vertices)
(known_dependences_p,build_empty_rdg, build_rdg, free_rdg): Same.
* gcc/tree-loop-distribution.c (distribute_loop): Same.
=== modified file 'gcc/cfgloopanal.c'
--- gcc/cfgloopanal.c 2012-05-31 20:19:00 +
+++ gcc/cfgloopanal.c 2012-08-18 16:43:02 +
@@ -93,8 +93,14 @@ mark_irreducible_loops (void)
e->flags &= ~EDGE_IRREDUCIBLE_LOOP;
}
+ if (graph_obstack == NULL)
+{
+ graph_obstack = XNEW (struct obstack);
+ obstack_init (graph_obstack);
+}
+
/* Create the edge lists. */
- g = new_graph (last_basic_block + num);
+ g = new_graph (last_basic_block + num, graph_obstack);
FOR_BB_BETWEEN (act, ENTRY_BLOCK_PTR, EXIT_BLOCK_PTR, next_bb)
FOR_EACH_EDGE (e, ei, act->succs)
@@ -134,7 +140,7 @@ mark_irreducible_loops (void)
src = LOOP_REPR (cloop);
}
- add_edge (g, src, dest)->data = e;
+ add_edge (g, src, dest, graph_obstack)->data = e;
}
/* Find the strongly connected components. */
@@ -161,7 +167,8 @@ mark_irreducible_loops (void)
real->src->flags |= BB_IRREDUCIBLE_LOOP;
}
- free_graph (g);
+ /* Destroy all data allocated for the graph. */
+ XOBDELETE (graph_obstack, g);
loops_state_set (LOOPS_HAVE_MARKED_IRREDUCIBLE_REGIONS);
return irred_loop_found;
=== modified file 'gcc/dominance.c'
--- gcc/dominance.c 2012-08-14 15:59:41 +
+++ gcc/dominance.c 2012-08-18 16:43:02 +
@@ -1341,7 +1341,13 @@ iterate_fix_dominators (enum cdi_directi
}
*pointer_map_insert (map, ENTRY_BLOCK_PTR) = (void *) (size_t) n;
- g = new_graph (n + 1);
+ if (graph_obstack == NULL)
+{
+ graph_obstack = XNEW (struct obstack);
+ obstack_init (graph_obstack);
+}
+
+ g = new_graph (n + 1, graph_obstack);
for (y = 0; y < g->n_vertices; y++)
g->vertices[y].data = BITMAP_ALLOC (NULL);
FOR_EACH_VEC_ELT (basic_block, bbs, i, bb)
@@ -1358,7 +1364,7 @@ iterate_fix_dominators (enum cdi_directi
if (!bitmap_set_bit ((bitmap) g->vertices[dom_i].data, i))
continue;
- add_edge (g, dom_i, i);
+ add_edge (g, dom_i, i, graph_obstack);
}
}
for (y = 0; y < g->n_vertices; y++)
@@ -1392,7 +1398,8 @@ iterate_fix_dominators (enum cdi_directi
free (brother);
free (parent);
- free_graph (g);
+ /* Destroy all data allocated for the graph. */
+ XOBDELETE (graph_obstack, g);
}
void
=== modified file 'gcc/graphds.c'
--- gcc/graphds.c 2009-11-25 10:55:54 +
+++ gcc/graphds.c 2012-08-18 16:43:02 +
@@ -53,28 +53,29 @@ dump_graph (FILE *f, struct graph *g)
}
}
-/* Creates a new graph with N_VERTICES vertices. */
+/* Creates a new graph with N_VERTICES vertices from obstack O. */
struct graph *
-new_graph (int n_vertices)
+new_graph (int n_vertices, struct obstack *o)
{
- struct graph *g = XNEW (struct graph);
+ struct graph *g = XOBNEW (o, struct graph);
g->n_vertices = n_vertices;
- g->vertices = XCNEWVEC (struct vertex, n_vertices);
+ g->vertices = XOBNEWVEC (o, struct vertex, n_vertices);
+ memset (g->vertices, 0, n_vertices * sizeof (*g->vertices));
return g;
}
-/* Adds an edge from F to T to graph G. The new edge is returned. */
+/* Adds an edge from F to T to graph G. Allocations are from obstack O. The
+ new edge is returned. */
str
Re: [PATCH] Fix -fcompare-debug failure in fwprop (PR rtl-optimization/54294)
Il 17/08/2012 22:00, Jakub Jelinek ha scritto:
> Hi!
>
> As discussed in the PR, this patch, originally posted for PR42728,
> makes sure the shortcut in all_uses_available_at is used on the same insns
> in between -g and -g0, it is the second time a -fcompare-debug failure
> resulted from NEXT_INSN being something different with -g, so IMHO it is
> desirable to commit this.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, and in the PR
> Uros wrote he bootstrapped/regtested it on alphaev8-linux. Ok for trunk?
Can't approve, but it looks like the right approach since debug insns
aren't "real" defs.
Paolo
> Then the PR discussed what to do with the remaining issues, any feedback on
> that would be appreciated.
>
> 2012-08-17 Jakub Jelinek
>
> PR rtl-optimization/54294
> * fwprop.c (all_uses_available_at): Ignore debug insns in between
> def_insn and target_insn when checking whether the shortcut is
> possible.
>
> --- gcc/fwprop.c.jj 2012-08-15 10:55:21.0 +0200
> +++ gcc/fwprop.c 2012-08-17 11:15:55.624101951 +0200
> @@ -799,13 +799,17 @@ all_uses_available_at (rtx def_insn, rtx
>df_ref *use_rec;
>struct df_insn_info *insn_info = DF_INSN_INFO_GET (def_insn);
>rtx def_set = single_set (def_insn);
> + rtx next;
>
>gcc_assert (def_set);
>
>/* If target_insn comes right after def_insn, which is very common
> - for addresses, we can use a quicker test. */
> - if (NEXT_INSN (def_insn) == target_insn
> - && REG_P (SET_DEST (def_set)))
> + for addresses, we can use a quicker test. Ignore debug insns
> + other than target insns for this. */
> + next = NEXT_INSN (def_insn);
> + while (next && next != target_insn && DEBUG_INSN_P (next))
> +next = NEXT_INSN (next);
> + if (next == target_insn && REG_P (SET_DEST (def_set)))
> {
>rtx def_reg = SET_DEST (def_set);
>
>
> Jakub
>
Re: PATCH: Add x32 support to config.guess
On Saturday 18 August 2012 14:01:57 H.J. Lu wrote: > On Sat, Aug 18, 2012 at 10:40 AM, Mike Frysinger wrote: > > On Saturday 18 August 2012 13:32:59 Mike Stump wrote: > >> On Aug 18, 2012, at 6:52 AM, "H.J. Lu" wrote: > >> > In case of x32, the only difference between x32 and x86-64 is > >> > the default output of CC. What do you recommend how to > >> > detect x32? > >> > >> So, is there a cpp symbol that is defined for code-gen? If so, > >> something like > >> > >> If [ $(gcc -x c /dev/null -dM -E | grep x32) = x32 ]; then fi > >> > >> Would do it. > > > > how is executing `gcc` any better than $CC_FOR_BUILD ? > > > > your code suggestion here is pretty much what H.J. Lu is already doing. > > There are 12 existing set_cc_for_build usages in config.guess. > I don't think it is reasonable to require x32 not to use it without > providing an alternative. If you want to remove set_cc_for_build, > one extra usage doesn't make it much harder to do. (in case it wasn't clear, i'm in favor of H.J. Lu's patch) -mike signature.asc Description: This is a digitally signed message part.
more malloc mitigation
Hi,
2012-08-18 Dimitrios Apostolou
* gcc/tree-ssa-sccvn.c (struct vn_tables_s): Add obstack_start to
mark the first allocated object on the obstack.
(process_scc, allocate_vn_table): Use it.
(init_scc_vn): Don't truncate shared_lookup_references vector.
(prealloc_ref_ops_vec): New static vector.
(create_reference_ops_from_ref, create_reference_ops_from_call):
Use it instead of locally allocated one.
(free_scc_vn): Truncate vectors to 0, but keep them most 16 slots
long.
I'd have used a stack vector for create_reference_ops_from_{ref,call}
instead of a static one on the heap, but the functions return heap
vectors. Can I just cast a stack vector to a heap one?
Also is it acceptable to leak 4K because of never freeing the whole
obstack?
Tested on x86 with old snapshot, will post update soon after testing with
more recent one.
Thanks,
Dimitris2012-08-18 Dimitrios Apostolou
* gcc/tree-ssa-sccvn.c (struct vn_tables_s): Add obstack_start to
mark the first allocated object on the obstack.
(process_scc, allocate_vn_table): Use it.
(init_scc_vn): Don't truncate shared_lookup_references vector.
(prealloc_ref_ops_vec): New static vector.
(create_reference_ops_from_ref, create_reference_ops_from_call):
Use it instead of locally allocated one.
(free_scc_vn): Truncate vectors to 0, but keep them most 16 slots
long.
=== modified file 'gcc/tree-ssa-sccvn.c'
--- gcc/tree-ssa-sccvn.c2012-08-16 14:27:51 +
+++ gcc/tree-ssa-sccvn.c2012-08-18 16:43:02 +
@@ -105,6 +105,7 @@ typedef struct vn_tables_s
htab_t phis;
htab_t references;
struct obstack nary_obstack;
+ long *obstack_start;
alloc_pool phis_pool;
alloc_pool references_pool;
} *vn_tables_t;
@@ -973,16 +974,21 @@ copy_reference_ops_from_call (gimple cal
}
}
+/* Preallocated vector with sufficient space - see free_scc_vn(). Helps to
+ avoid reallocations and space, since when we VEC_copy() it, only its exact
+ length is duplicated. */
+
+static VEC(vn_reference_op_s, heap) *prealloc_ref_ops_vec;
+
/* Create a vector of vn_reference_op_s structures from REF, a
- REFERENCE_CLASS_P tree. The vector is not shared. */
+ REFERENCE_CLASS_P tree. The vector is not shared. */
static VEC(vn_reference_op_s, heap) *
create_reference_ops_from_ref (tree ref)
{
- VEC (vn_reference_op_s, heap) *result = NULL;
-
- copy_reference_ops_from_ref (ref, &result);
- return result;
+ VEC_truncate (vn_reference_op_s, prealloc_ref_ops_vec, 0);
+ copy_reference_ops_from_ref (ref, &prealloc_ref_ops_vec);
+ return VEC_copy (vn_reference_op_s, heap, prealloc_ref_ops_vec);
}
/* Create a vector of vn_reference_op_s structures from CALL, a
@@ -991,10 +997,9 @@ create_reference_ops_from_ref (tree ref)
static VEC(vn_reference_op_s, heap) *
create_reference_ops_from_call (gimple call)
{
- VEC (vn_reference_op_s, heap) *result = NULL;
-
- copy_reference_ops_from_call (call, &result);
- return result;
+ VEC_truncate (vn_reference_op_s, prealloc_ref_ops_vec, 0);
+ copy_reference_ops_from_call (call, &prealloc_ref_ops_vec);
+ return VEC_copy (vn_reference_op_s, heap, prealloc_ref_ops_vec);
}
/* Fold *& at position *I_P in a vn_reference_op_s vector *OPS. Updates
@@ -3610,8 +3615,9 @@ process_scc (VEC (tree, heap) *scc)
htab_empty (optimistic_info->nary);
htab_empty (optimistic_info->phis);
htab_empty (optimistic_info->references);
- obstack_free (&optimistic_info->nary_obstack, NULL);
- gcc_obstack_init (&optimistic_info->nary_obstack);
+ /* Quick way to empty the obstack but keep it ready for reuse. */
+ obstack_free (&optimistic_info->nary_obstack,
+ optimistic_info->obstack_start);
empty_alloc_pool (optimistic_info->phis_pool);
empty_alloc_pool (optimistic_info->references_pool);
FOR_EACH_VEC_ELT (tree, scc, i, var)
@@ -3796,6 +3802,7 @@ allocate_vn_table (vn_tables_t table)
free_reference);
gcc_obstack_init (&table->nary_obstack);
+ table->obstack_start = XOBNEW (&table->nary_obstack, long);
table->phis_pool = create_alloc_pool ("VN phis",
sizeof (struct vn_phi_s),
30);
@@ -3842,7 +3849,6 @@ init_scc_vn (void)
gcc_obstack_init (&vn_ssa_aux_obstack);
shared_lookup_phiargs = NULL;
- shared_lookup_references = NULL;
rpo_numbers = XNEWVEC (int, last_basic_block);
rpo_numbers_temp = XNEWVEC (int, n_basic_blocks - NUM_FIXED_BLOCKS);
pre_and_rev_post_order_compute (NULL, rpo_numbers_temp, false);
@@ -3887,9 +3893,19 @@ free_scc_vn (void)
htab_delete (constant_to_value_id);
BITMAP_FREE (constant_value_ids);
VEC_free (tree, heap, shared_lookup_phiargs);
- VEC_free (vn_reference_op_s, heap, shared_lookup_references);
XDELETEVEC (rpo_
[Fortran, committed] Add the working testcase for PR fortran/29290
Hello,
the reported case in PR fortran/29290 is now rejected as expected.
I have dejagnu-fied it and committed as obvious.
Mikael
PS: the PR can't be closed as the runtime behaviour mandated by the
standard isn't respected (the wrong procedure is called).
Index: gfortran.dg/interface_37.f90
===
--- gfortran.dg/interface_37.f90 (révision 0)
+++ gfortran.dg/interface_37.f90 (révision 190504)
@@ -0,0 +1,16 @@
+! { dg-do compile }
+!
+! PR fortran/39290
+! Subroutine/function ambiguity in generics.
+!
+ interface q
+ subroutine qr(f)
+ implicit real(f)
+ external f
+ end subroutine
+ subroutine qc(f)
+ implicit complex(f)
+ external f
+ end subroutine ! { dg-error "Ambiguous interfaces" }
+ end interface q
+ end
Index: ChangeLog
===
--- ChangeLog (révision 190503)
+++ ChangeLog (révision 190504)
@@ -1,3 +1,8 @@
+2012-08-18 Mikael Morin
+
+ PR fortran/39290
+ * gfortran.dg/interface_37.f90: New test.
+
2012-08-17 H.J. Lu
Gary Funck
[committed] Fix PR middle-end/53823
This change fixes PR middle-end/53823. The negative variant of
synth_mult doesn't handle modes larger than a host wide int.
Approved by rth in PR.
Tested on hppa2.0w-hp-hpux11.11 and hppa64-hp-hpux11.11.
Dave
--
J. David Anglin dave.ang...@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
2012-08-18 John David Anglin
PR middle-end/53823
* expmed.c (expand_mult): Skip synth_mult for negative coefficients
if the mode is larger than a wide int and it is too costly to multiply
by a positive multiplier and negate the result.
Index: expmed.c
===
--- expmed.c(revision 190317)
+++ expmed.c(working copy)
@@ -3261,7 +3261,6 @@
/* Attempt to handle multiplication of DImode values by negative
coefficients, by performing the multiplication by a positive
multiplier and then inverting the result. */
- /* ??? How is this not slightly redundant with the neg variant? */
if (is_neg && mode_bitsize > HOST_BITS_PER_WIDE_INT)
{
/* Its safe to use -coeff even for INT_MIN, as the
@@ -3278,6 +3277,7 @@
&algorithm, variant);
return expand_unop (mode, neg_optab, temp, target, 0);
}
+ goto skip_synth;
}
/* Exclude cost of op0 from max_cost to match the cost
[wwwdocs] SH 4.8 changes update
Hello, This is what has been done so far on the SH side for 4.8. I hope it's OK. Cheers, Oleg Index: htdocs/gcc-4.8/changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.8/changes.html,v retrieving revision 1.10 diff -u -r1.10 changes.html --- htdocs/gcc-4.8/changes.html 10 Aug 2012 16:25:46 - 1.10 +++ htdocs/gcc-4.8/changes.html 19 Aug 2012 00:41:33 - @@ -100,6 +100,70 @@ options to the assembler. +SH + +The default alignment settings have been reduced to be less aggresive. +This results in more compact code for optimization levels other than +-Os. + +Improved support for the __atomic built-in functions: + + Minor tweaks for code around software atomic sequences that are + enabled by -msoft-atomic. + + A new option -menable-tas will make the compiler + generate the tas.b instruction for the + __atomic_test_and_set built-in function. + + The SH4A instructions movco.l and + movli.l are now supported. They are used to implement some + software atomic sequences that are enabled by -msoft-atomic. + In addition to that, pure movco.l / movli.l + atomic sequences can be enabled with the new option + -mhard-atomic. + + +Added support for the mov.b and mov.w +instructions with displacement addressing. + +Added support for the SH2A instructions movu.b and +movu.w. + +Various improvements to code generated for integer arithmetic. + +Improvements to conditional branches and code that involves the T bit. +A new option -mzdcbranch tells the compiler to favor +zero-displacement branches. This is enabled by default for SH4 and +SH4A. + +The pref instruction will now be emitted by the +__builtin_prefetch built-in function for SH3. + +The fmac instruction will now be emitted by the +fmaf standard and built-in function. + +The -mfused-madd option has been depricated in favor of +the machine-independent -ffp-contract option. Notice that the +fmac instruction will now be generated by default for +expressions like a * b + c. This is due to the compiler +default setting -ffp-contract=fast. + +Added new options -mfsrra and -mfsca to allow +the compiler using the fsrra and fsca +instructions on CPUs other than SH4A. + +Added support for the __builtin_bswap32 built-in function. +It is now expanded as a sequence of swap.b and +swap.w instructions instead of a library function call. + +The behavior of the -mieee option has been fixed and the +negative form -mno-ieee has been added to control the IEEE +conformance of floating point comparisons. By default-mieee is +now enabled and the option -ffinite-math-only implicitly sets +-mno-ieee. + + +
Re: [wwwdocs] SH 4.8 changes update
Oleg Endo wrote: > This is what has been done so far on the SH side for 4.8. > I hope it's OK. Looks fine to me. Regards, kaz
Inline hints
Hi,
this patch implements infrastructure for inline hints. They provide way to pass
info
down from inline-analysis to the inline heuristic implementation that does not
fit the
current size/time model. Inline hints are simple bitmask of individual hints
that are
interprested by the heuristics as fit.
The patch implement only one hint that is to prioritize inlining of function
when devirtualization or indirect call removal will happen.
We will need bit expriments on how to interpret these hints. Currently for
autoinined functions we bypass inline-insns-auto limit and for functions
declared
inline we bypass inline-insns-single limit. Also badness is decreased by factor
of 8.
This was my first try and it works pretty well in practice.
On Mozilla this increase number of devirutalization from 160 to 2080, that is
non-zero
precentage of overalll 66000 virtual calls. This does not translate exactly
into
decarese of indirect calls in mozill abinary that goes down by only about 500.
Still it is a lot better than anticipated and for a fist time we devirtualize
non-joke
number of calls.
I intend to follow with more hints. The followng are ones I experimented with
so far:
1) to penalize inlining within strongly connected component since it usually
cause
complex cgraphs/cfgs (to help povray)
2) to enable more inlining when loop bounds become known (to help fortran)
3) to enable more inlining when loop stride become known (also for fortran
mostly)
4) to enable more inlining when when caller/callee is known to be hot
(by profile or attribute)
Bootstrapped/regtested x86_64-linux, will commit it shortly.
Honza
* gcc.dg/ipa/iinline-1.c: Update testcase to test inline hints.
* ipa-inline.c (want_inline_small_function_p): Bypass
inline limits for hinted functions.
(edge_badness): Dump hints; decrease badness for hinted funcitons.
* ipa-inline.h (enum inline_hints_vals): New enum.
(inline_hints): New type.
(edge_growth_cache_entry): Add hints.
(dump_inline_summary): Update.
(dump_inline_hints): Declare.
(do_estimate_edge_hints): Declare.
(estimate_edge_hints): New inline function.
(reset_edge_growth_cache): Update.
* predict.c (cgraph_maybe_hot_edge_p): Do not ice on indirect edges.
* ipa-inline-analysis.c (dump_inline_hints): New function.
(estimate_edge_devirt_benefit): Return true when function should be
hinted.
(estimate_calls_size_and_time): New hints argument; set it when
devritualization happens.
(estimate_node_size_and_time): New hints argument.
(do_estimate_edge_time): Cache hints.
(do_estimate_edge_growth): Update.
(do_estimate_edge_hints): New function
Index: testsuite/gcc.dg/ipa/iinline-1.c
===
*** testsuite/gcc.dg/ipa/iinline-1.c(revision 190508)
--- testsuite/gcc.dg/ipa/iinline-1.c(working copy)
***
*** 1,7
/* Verify that simple indirect calls are inlined even without early
inlining.. */
/* { dg-do compile } */
! /* { dg-options "-O3 -c -fdump-ipa-inline -fno-early-inlining" } */
extern void non_existent(int);
--- 1,7
/* Verify that simple indirect calls are inlined even without early
inlining.. */
/* { dg-do compile } */
! /* { dg-options "-O3 -c -fdump-ipa-inline -fno-early-inlining -fno-ipa-cp" }
*/
extern void non_existent(int);
*** int test (void)
*** 22,26
--- 22,27
return 0;
}
+ /* { dg-final { scan-ipa-dump "indirect_call" "inline" } } */
/* { dg-final { scan-ipa-dump "hooray\[^\\n\]*inline copy in test" "inline"
} } */
/* { dg-final { cleanup-ipa-dump "inline" } } */
Index: ipa-inline.c
===
*** ipa-inline.c(revision 190508)
--- ipa-inline.c(working copy)
*** want_inline_small_function_p (struct cgr
*** 472,482
else
{
int growth = estimate_edge_growth (e);
if (growth <= 0)
;
else if (DECL_DECLARED_INLINE_P (callee->symbol.decl)
! && growth >= MAX_INLINE_INSNS_SINGLE)
{
e->inline_failed = CIF_MAX_INLINE_INSNS_SINGLE_LIMIT;
want_inline = false;
--- 472,486
else
{
int growth = estimate_edge_growth (e);
+ inline_hints hints = estimate_edge_hints (e);
if (growth <= 0)
;
+ /* Apply MAX_INLINE_INSNS_SINGLE limit. Do not do so when
+hints suggests that inlining given function is very profitable. */
else if (DECL_DECLARED_INLINE_P (callee->symbol.decl)
! && growth >= MAX_INLINE_INSNS_SINGLE
! && !(hints & INLINE_HINT_indirect_call))
{
e->inline_failed = CIF_MAX_INLINE_INSNS_SINGLE_LIMIT;
want_inline = false;
**
Re: [PATCH] Fix AVR fallout
2012/8/18 Jan-Benedict Glaw : > Hi! > > I see these warnings/errors right now: > > g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing > -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes > -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros > -Wno-overlength-strings -Wold-style-definition -Wc++-compat -fno-common > -DHAVE_CONFIG_H -I. -I. -I../../../../gcc/gcc -I../../../../gcc/gcc/. > -I../../../../gcc/gcc/../include -I../../../../gcc/gcc/../libcpp/include > -I../../../../gcc/gcc/../libdecnumber > -I../../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber-I. -I. > -I../../../../gcc/gcc -I../../../../gcc/gcc/. > -I../../../../gcc/gcc/../include -I../../../../gcc/gcc/../libcpp/include > -I../../../../gcc/gcc/../libdecnumber > -I../../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber > ../../../../gcc/gcc/config/avr/avr-log.c > cc1plus: warning: command line option ‘-Wstrict-prototypes’ is valid for > C/ObjC but not for C++ [enabled by default] > cc1plus: warning: command line option ‘-Wmissing-prototypes’ is valid for > C/ObjC but not for C++ [enabled by default] > cc1plus: warning: command line option ‘-Wold-style-definition’ is valid for > C/ObjC but not for C++ [enabled by default] > cc1plus: warning: command line option ‘-Wc++-compat’ is valid for C/ObjC but > not for C++ [enabled by default] > ../../../../gcc/gcc/config/avr/avr-log.c: In function ‘void > avr_log_vadump(FILE*, const char*, va_list)’: > ../../../../gcc/gcc/config/avr/avr-log.c:287:22: warning: ‘machine_mode’ is > promoted to ‘int’ when passed through ‘...’ [enabled by default] > ../../../../gcc/gcc/config/avr/avr-log.c:287:22: note: (so you should pass > ‘int’ not ‘machine_mode’ to ‘va_arg’) > ../../../../gcc/gcc/config/avr/avr-log.c:287:22: note: if this code is > reached, the program will abort > ../../../../gcc/gcc/config/avr/avr-log.c:291:31: warning: ‘rtx_code’ is > promoted to ‘int’ when passed through ‘...’ [enabled by default] > ../../../../gcc/gcc/config/avr/avr-log.c:291:31: note: if this code is > reached, the program will abort > ../../../../gcc/gcc/config/avr/avr-log.c:295:38: warning: ‘reg_class’ is > promoted to ‘int’ when passed through ‘...’ [enabled by default] > ../../../../gcc/gcc/config/avr/avr-log.c:295:38: note: if this code is > reached, the program will abort > > [...] > > g++ -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing > -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes > -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros > -Wno-overlength-strings -Wold-style-definition -Wc++-compat -fno-common > -DHAVE_CONFIG_H -I. -I. -I../../../../gcc/gcc -I../../../../gcc/gcc/. > -I../../../../gcc/gcc/../include -I../../../../gcc/gcc/../libcpp/include > -I../../../../gcc/gcc/../libdecnumber > -I../../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber-I. -I. > -I../../../../gcc/gcc -I../../../../gcc/gcc/. > -I../../../../gcc/gcc/../include -I../../../../gcc/gcc/../libcpp/include > -I../../../../gcc/gcc/../libdecnumber > -I../../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber > ../../../../gcc/gcc/config/avr/gen-avr-mmcu-texi.c -o gen-avr-mmcu-texi > cc1plus: warning: command line option ‘-Wstrict-prototypes’ is valid for > C/ObjC but not for C++ [enabled by default] > cc1plus: warning: command line option ‘-Wmissing-prototypes’ is valid for > C/ObjC but not for C++ [enabled by default] > cc1plus: warning: command line option ‘-Wold-style-definition’ is valid for > C/ObjC but not for C++ [enabled by default] > cc1plus: warning: command line option ‘-Wc++-compat’ is valid for C/ObjC but > not for C++ [enabled by default] > ../../../../gcc/gcc/config/avr/gen-avr-mmcu-texi.c: In function ‘int main()’: > ../../../../gcc/gcc/config/avr/gen-avr-mmcu-texi.c:53:24: error: invalid > conversion from ‘int’ to ‘avr_arch’ [-fpermissive] > ../../../../gcc/gcc/config/avr/gen-avr-mmcu-texi.c:75:23: error: invalid > conversion from ‘int’ to ‘avr_arch’ [-fpermissive] > make[3]: *** [gen-avr-mmcu-texi] Error 1 > make[3]: Leaving directory `/mnt/devel/src/linux/build/avr/gcc-stage1/gcc' > make[2]: *** [all-gcc] Error 2 > make[2]: Leaving directory `/mnt/devel/src/linux/build/avr/gcc-stage1' > > > I suggest this patch. Okay? > > > > 2012-08-17 Jan-Benedict Glaw > > gcc/Changelog: > * config/avr/avr-log.c (avr_log_vadump): Properly use > int-promoted enum values. > * config/avr/avr.h (struct mcu_type_s): Change `arch' from > int to enum avr_arch. > * config/avr/gen-avr-mmcu-texi.c (main): Use correct initializer. > > Thank you for the fix. Committed. Denis.
