Re: 0005-Switch-Core-2-to-new-tuning

On Tue, Nov 30, 2010 at 01:51:41PM +0100, Uros Bizjak wrote:
> On Tue, Nov 30, 2010 at 1:39 PM, Maxim Kuvyrkov <maxim <at> codesourcery.com> wrote:
> > This patch switches Core 2 to "new" tuning that Core i7 uses.
> >
> > The "new" tuning very much resembles tuning for generic32 and generic64 CPUs.  Generic tuning appears
to provide best performance results on Core 2/i7 hardware.
> >
> > OK for trunk?
> 
> Can you please summarize SPEC2k, SPEC2k6 and Polyhedron results for
> patched and unpatched gcc?
> 
> Thanks,
> Uros.

Uros,
   On x86-apple-darwin10, benchmarking the Polyhedron 2005 suite using a dual 2.8 GHz
Xeon 2008 MacPro, I get the following results with -mtune=generic and -mtune=core2
at -m64 and -m32. These are for r167305 with both 0005-Switch-Core-2-to-new-tuning
and 0006-Core-2-i7-DFA applied.

x86_64-apple-darwin10 target
Compile Command : gfortran -mtune=XXXX -ffast-math -funroll-loops -O3 %n.f90 -o %n

benchmark      -mtune=generic   -mtune=core2  %change
ac                  8.90            8.81       -1.0
aermod             17.23           17.34       +0.6
air                 5.57            5.56       -0.2
capacita           32.64           32.77       +0.4
channel             1.84            1.84        0.0

Re: [PATCH: PR target/46631] Change operands order so we can use 16bit AND instead of 32bit in thumb2

On Tue, Nov 30, 2010 at 3:28 PM, Andrew Pinski <pinskia <at> gmail.com> wrote:
> On Tue, Nov 30, 2010 at 3:21 PM, Carrot Wei <carrot <at> google.com> wrote:
>> Hi
>>
>> An instruction of the following style is 32 bit in thumb2.
>>    and    r2, r3, r2
>>
>> If we change the source operands order, it will be 16 bit.
>>    ands    r2, r2, r3
>>
>> This patch contains a new peephole2 to detect the situation that the all 3
>> operands of AND are low registers, and the target is the same as the second
>> source, then replace it with another AND with its source operands exchanged.
>
>
> Looking at what thumb1 does:
>      if (GET_CODE (operands[2]) != CONST_INT)
>        {
>          rtx tmp = force_reg (SImode, operands[2]);
>          if (rtx_equal_p (operands[0], operands[1]))
>            operands[2] = tmp;
>          else
>            {
>              operands[2] = operands[1];
>              operands[1] = tmp;
>            }
>        }
> I almost think thumb2 should do the same (maybe it should be done
> always in the arm back-end).
>

Re: [PATCH: PR target/46631] Change operands order so we can use 16bit AND instead of 32bit in thumb2

On Tue, Nov 30, 2010 at 4:02 PM, Carrot Wei <carrot <at> google.com> wrote:
> That's too early, all are in pseudo registers. I think it may miss some cases.

Oh I see it now, I think.  Though it might help in general and make
thumb less generic.

-- Pinski

Fix PR45199: do not aggregate memory accesses to the same array for -ftree-loop-distribute-patterns

Hi,

This patch disables for -ftree-loop-distribute-patterns a heuristic
that is used by the loop distribution pass to avoid the split of loops
with reads and writes to the same array, like this loop:

loop
  A[2*i] = 0
  A[2*i+1] = 1
end_loop

would be transformed into these two loops:

loop
  A[2*i] = 0
end_loop

loop
  A[2*i+1] = 1
end_loop

and that would hurt data locality.  Now, because we don't want these
two loops to be distributed when -ftree-loop-distribute-patterns is
enabled, we have to select the seeds of the memset (0) partitions to
be only those statements "A[i] = 0" that also satisfy the test in
generate_memset_zero, that is dataref_stride_has_unit_type_stride.

Bootstrap and test in progress on amd64-linux.  Ok for trunk when that
passes?

[Ian Lance Taylor] PATCH RFC: Simplify ASM_SPEC in config/i386

There were no comments on this patch.  I have committed it to mainline.

Ian

From: Ian Lance Taylor <iant <at> google.com>
Subject: PATCH RFC: Simplify ASM_SPEC in config/i386
Date: 2010-11-23 00:21:49 GMT

The various instances of ASM_SPEC in config/i386 have evidently been
copied from one another, and were originally copied from the ASM_SPEC
now in config/sol2.h.  That ASM_SPEC has these specs:

%{v:-V} %{Qy:} %{!Qn:-Qy} %{n} %{T} %{Ym,*} %{Yd,*}

None of these make sense when using the GNU assembler.  The GNU
assembler handles -V like -v anyhow.  The -Qy and -Qn options are
no-ops.  The -n option means to not emit nop instructions for alignment
within code sections; this differs from the Solaris assembler -n option,
which means to suppress warnings.  The -T and -Y options are errors for
the GNU assembler.

Also, the spec

ObjC/ObjC++: fixes for parsing of <at> throw

This small patch fixes a couple of small bugs in the Objective-C++ parser.

I reviewed the parsing of  <at> throw in Objective-C and Objective-C++ and looked
at testcases from other compilers.  It all looks good in our compiler with the 
exception of a couple of very minor issues that this patch fixes.

The main one is that upon finding

  <at> throw;

outside of a  <at> catch block, the Objective-C++ compiler would not recovery properly
from the error, and would cause spurious errors on the next statement.  I fixed that.

The second one is that the Objective-C compiler allowed

  <at> throw object1, object2;

while the Objective-C++ didn't.  I allowed it for the Objective-C++ compiler as well
(clang allows it both for ObjC and ObjC++).

A testcase for ObjC and one for ObjC++ are included.

Ok to commit ?

Thanks

Index: gcc/objc/objc-act.c
===================================================================
--- gcc/objc/objc-act.c (revision 167318)
+++ gcc/objc/objc-act.c (working copy)

Finish toplev.h cleanup

This patch completes cleaning up toplev.h and includes of toplev.h
along the lines I proposed in
<http://gcc.gnu.org/ml/gcc-patches/2010-11/msg02934.html>.  Various
declarations move to other files as listed there, and files that no
longer need toplev.h includes have them removed.  (This time I checked
the files still including toplev.h to avoid false positives from grep
where a function name was only mentioned in a comment or as a
substring of another function name, so that toplev.h was not in fact
needed although an initial grep suggested it was.  Thus, I think all
remaining includes of toplev.h - 58 of them - are actually needed at
present.)

Bootstrapped with no regressions on x86_64-unknown-linux-gnu.  Also
tested building cc1 for crosses to: alpha-linux-gnu arc-elf arm-eabi
avr-elf bfin-elf cris-elf crx-elf fr30-elf frv-elf h8300-elf ia64-elf
iq2000-elf lm32-elf m32c-elf m32r-elf m68hc11-elf m68k-elf mcore-elf
mep-elf microblaze-elf mips-elf mmix-knuth-mmixware mn10300-elf
moxie-elf hppa-linux-gnu pdp11-none picochip-none s390-linux-gnu
score-elf sh-elf sparc-elf spu-elf xstormy16-elf v850-elf
vax-linux-gnu xtensa-elf.  OK to commit?

2010-11-30  Joseph Myers  <joseph <at> codesourcery.com>

	* common.opt (main_input_filename, main_input_basename,
	main_input_baselength): New Variable entries.  From toplev.c.
	* final.c (output_quoted_string): Move from toplev.c.
	* output.h (output_quoted_string): Move from toplev.h.
	* opts-global.c (read_cmdline_options): Use gcc_options pointer to
	access main_input_filename, main_input_baselength and
	main_input_basename.

[PATCH] [c++][ada][middle-end] Remove redundant GTY markers from structs

I am working on a patch to diagnose redundant GTY markers.  It is not completed (possibly
it will not be completed at all, at least not for 4.6: it is likely that to get false
positive numbers to zero it will be necessary to preprocess GTY input), but it is already
useful to remove some GTY instances in GCC.

Bootstrapped r167283 with this patch and regtested against r167293 with no regressions on
x86_64/linux.

OK for trunk?

Also, while preparing this patch I have noticed that some of these types (for example,
struct edge_prediction) are used in a single source file only.  I will prepare a patch to
move them.

2010-11-30  Laurynas Biveinis  <laurynas.biveinis <at> gmail.com>

	* tree.h (struct call_expr_arg_iterator_d): Remove GTY tag.
	(const_call_expr_arg_iterator_d): Likewise.
	(expanded_location): Likewise.
	* c-tree.h (struct c_arg_tag_d): Likewise.
	* dwarf2out.c (struct cfa_loc): Likewise.
	(struct skeleton_chain_struct): Likewise.
	* except.c (struct ttypes_filter): Likewise.
	* cselib.h (struct cselib_val_struct): Likewise.
	(elt_loc_list): Likewise.
	(elt_list): Likewise.
	* varasm.c (struct addr_const): Likewise.
	* tree-flow.h (struct edge_prediction): Likewise.
	(struct int_tree_map): Likewise.
	(struct _edge_var_map): Likewise.

RFA: hookize BOOL_TYPE_SIZE and ADA_LONG_TYPE_SIZE

bootstrapped & regtested on x86_64-pc-linux-gnu
cross-tested on x86_64-pc-linux-gnu for the following targets:
ppc-darwin
alpha-linux-gnu hppa-linux-gnu mips-elf sh-elf arc-elf ia64-elf sparc-elf
arm-eabi iq2000-elf mn10300-elf spu-elf avr-elf lm32-elf moxie-elf v850-elf
m32c-elf pdp11-aout cris-elf m32r-elf picochip-elf xstormy16-elf  
crx-elf m68hc11-elf ppc-elf xtensa-elf fr30-elf m68k-elf rx-elf  
mcore-elf
s390-linux-gnu h8300-elf mep-elf score-elf

bootstrapped on i686-pc-linux-gnu
cross-tested on i686-pc-linux-gnu for targets:
bfin-elf frv-elf mmix-knuth-mmixware vax-linux-gnu

Ada testing for microblaze is currently not possible because of PR46738.

2010-12-01  Joern Rennecke  <amylaar <at> spamcop.net>

	PR other/46677
gcc:
	* doc/tm.texi: Regenerate.
	* doc/tm.texi.in (ADA_LONG_TYPE_SIZE, BOOL_TYPE_SIZE): Delete.
	(TARGET_ADA_LONG_TYPE_SIZE, TARGET_BOOL_TYPE_SIZE): New hook.
	* targhooks.c (default_bool_type_size): New function.
	(default_ada_long_type_size): Likewise.
	* targhooks.h (default_bool_type_size): Declare.
	(default_ada_long_type_size): Likewise.
	* hooks.c (hook_int_void_64): New function.

Re: [PATCH] Fix missing headers for plugin [was Miss head file diagnostic.h in plugin.h?]

* Joern Rennecke wrote on Tue, Nov 30, 2010 at 09:34:46PM CET:
> Mingjie Xing:
> >2010/11/30 Ralf Wildenhues:
> >>But then why is hard-reg-set.h not listed in FUNCTION_H? ?Generally,
> >>the *_H make macros in gcc/Makefile.in should correspond to directly
> >>included headers only (with some set of exceptions that I haven't really
> >>grokked yet, sorry).

> >I bet you are right. Putting hard-reg-set.h in FUNCTION_H seems
> >reasonable.  Here's the updated patch.
> 
> The problem is that function.h depends on a target-dependent type.
> See PR middle-end/46495

Are you suggesting that r167290 should be reverted for now?

Thanks,
Ralf