headers
Xinliang David Li | 1 Jun 2011 01:34
Picon
Favicon

-fdump-passes -fenable-xxx=func_name_list

The following patch implements the a new option that dumps gcc PASS
configuration. The sample output is attached.  There is one
limitation: some placeholder passes that are named with '*xxx' are
note registered thus they are not listed. They are not important as
they can not be turned on/off anyway.

The patch also enhanced -fenable-xxx and -fdisable-xx to allow a list
of function assembler names to be specified.

Ok for trunk?

Thanks,

David
Attachment (out): application/octet-stream, 9 KiB
Attachment (dump-pass.p): text/x-pascal, 21 KiB
Permalink | Reply | 27 comments |
headers
Xinliang David Li | 1 Jun 2011 02:01
Picon
Favicon

Re: New options to disable/enable any pass for any functions (issue4550056)

The new patch is attached. The test (c,c++,fortran, java, ada) is on going.

Thanks,

David

On Tue, May 31, 2011 at 9:06 AM, Xinliang David Li <davidxl <at> google.com> wrote:
> On Tue, May 31, 2011 at 2:05 AM, Richard Guenther
> <richard.guenther <at> gmail.com> wrote:
>> On Mon, May 30, 2011 at 10:16 PM, Xinliang David Li <davidxl <at> google.com> wrote:
>>> The attached are two simple follow up patches
>>>
>>> 1) the first patch does some refactorization on function header
>>> dumping (with more information printed)
>>>
>>> 2) the second patch cleans up some pass names. Part of the cleanup
>>> results from a previous discussion with Honza -- a) rename
>>> 'tree_profile_ipa' into 'profile', and make 'ipa_profile' and
>>> 'profile' into 'profile_estimate'. The rest of cleanups are needed to
>>> make sure pass names are unique.
>>>
>>> Ok for trunk?
>>
>> +
>> +void
>> +pass_dump_function_header (FILE *dump_file, tree fdecl, struct function *fun)
>>
>> This function needs documentation, the ChangeLog entry misses
>> the tree-pretty-print.h change.
>>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Xinliang David Li | 1 Jun 2011 02:02
Picon
Favicon

Re: New options to disable/enable any pass for any functions (issue4550056)

Honza, are you ok with the pass name change?

David

On Tue, May 31, 2011 at 2:07 AM, Richard Guenther
<richard.guenther <at> gmail.com> wrote:
> On Mon, May 30, 2011 at 11:44 PM, Xinliang David Li <davidxl <at> google.com> wrote:
>> This is the complete patch for pass name fixes (with test case changes).
>
> This is ok if Honza thinks the profile pass names make more sense this
> way.
>
> Thanks,
> Richard.
>
>> David
>>
>>
>> On Mon, May 30, 2011 at 1:16 PM, Xinliang David Li <davidxl <at> google.com> wrote:
>>> The attached are two simple follow up patches
>>>
>>> 1) the first patch does some refactorization on function header
>>> dumping (with more information printed)
>>>
>>> 2) the second patch cleans up some pass names. Part of the cleanup
>>> results from a previous discussion with Honza -- a) rename
>>> 'tree_profile_ipa' into 'profile', and make 'ipa_profile' and
>>> 'profile' into 'profile_estimate'. The rest of cleanups are needed to
>>> make sure pass names are unique.
>>>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jing Yu | 1 Jun 2011 02:02
Picon
Favicon

[google]Skip target-libiberty for arm*-*-linux-androideabi (issue4564050)

Building gcc-4.6 arm android toolchain fails because of conflicting
getpagesize() definition between libiberty and bionic.
Based on discussions on another thread
(http://www.mail-archive.com/gcc-patches <at> gcc.gnu.org/msg06627.html),
reviewer recommended ripping out all support for building libiberty
for the target side as it is not needed. However, I don't know if
someone is working on that. Before the ideal patch is out, we have to
clear the blocking issue and make the toolchain built.

The following patch simply skips building target-libiberty for
arm*-*-linux-androideabi target. I have tested the patch by
building arm-linux-androideabi toolchain.

I sent the similar patch to trunk for review. The patch to trunk
is slightly different because this part of configure.ac has been
modified. The logic is the same though.
http://gcc.gnu.org/ml/gcc-patches/2011-05/msg02457.html
The review is on going. I am not sure how long it would be.
I would suggest we first commit this tiny patch in google/main and
make our toolchain built. Then do further update if the trunk version is final.

Thanks,
Jing

2011-05-31  Jing Yu  <jingyu <at> google.com>

	* configure.ac: Skip target-libiberty for arm*-*-linux-androideabi
	* configure: Regenerate

Index: configure.ac
(Continue reading)

Permalink | Reply | 2 comments |
headers
Xinliang David Li | 1 Jun 2011 02:03
Picon
Favicon

Re: New options to disable/enable any pass for any functions (issue4550056)

Please discard the previous one. This is the right one:

David

On Tue, May 31, 2011 at 5:01 PM, Xinliang David Li <davidxl <at> google.com> wrote:
> The new patch is attached. The test (c,c++,fortran, java, ada) is on going.
>
> Thanks,
>
> David
>
> On Tue, May 31, 2011 at 9:06 AM, Xinliang David Li <davidxl <at> google.com> wrote:
>> On Tue, May 31, 2011 at 2:05 AM, Richard Guenther
>> <richard.guenther <at> gmail.com> wrote:
>>> On Mon, May 30, 2011 at 10:16 PM, Xinliang David Li <davidxl <at> google.com> wrote:
>>>> The attached are two simple follow up patches
>>>>
>>>> 1) the first patch does some refactorization on function header
>>>> dumping (with more information printed)
>>>>
>>>> 2) the second patch cleans up some pass names. Part of the cleanup
>>>> results from a previous discussion with Honza -- a) rename
>>>> 'tree_profile_ipa' into 'profile', and make 'ipa_profile' and
>>>> 'profile' into 'profile_estimate'. The rest of cleanups are needed to
>>>> make sure pass names are unique.
>>>>
>>>> Ok for trunk?
>>>
>>> +
>>> +void
(Continue reading)

Permalink | Reply | 3 comments |
headers
Diego Novillo | 1 Jun 2011 02:12
Picon
Favicon

[lto] Merge streamer hooks from pph branch. (issue4568043)


This patch merges the LTO streamer hooks from the pph branch.

These hooks are meant to separate streaming work that is specific to
GIMPLE from other modules that may want to stream their own data
structures.  In the PPH branch, we are using the streamer to save
front end data structures, so there was a bunch of work and checks
that made no sense in the front end.

All this module-specific work can be moved to the hooks defined in
struct lto_streamer_hooks.

One of the concerns I had with the hooks is potential overhead when
streaming because of the new indirect calls added by the patch.  This
does not seem to be the case.

I did several timing runs using insn-emit.o (the biggest object file
we generate in a bootstrap) and using an LTO link of cc1.  The times
are slightly in favour of the hooks, actually (the patch removes some
checks from the core tree pickling routines), but the difference is
insignificant.

Over 5 runs on an idle system: Without this patch, we compile
insn-emit.o in 41.56 secs (wall time), with the patch the time is
41.34 secs (wall time).

The other change in the patch is to reserve enough tags in enum
LTO_tags to cover all the possible tree codes.  This exposes the bug
that I fixed yesterday in the pph branch (the sign of the shifts in
lto_output_int_in_range).  This means that we need to use
(Continue reading)

Permalink | Reply | 6 comments |
headers
Gab Charette | 1 Jun 2011 04:50
Picon
Favicon

[pph] Renaming output/write and input/read to out/in + standardizing pph_stream_* to pph_* (issue4532102)

2011-05-31  Gabriel Charette  <gchare <at> google.com>

	* pph-streamer-in.c (pph_unpack_value_fields): Rename from pph_stream_unpack_value_fields.
	Update all users.
	(pph_init_read): Rename from pph_stream_init_read.
	Update all users.
	(pph_in_shared_data): Rename from pph_stream_read_shared_data.
	Update all users.
	(pph_register_shared_data): Rename from pph_stream_register_shared_data.
	Update all users.
	(pph_in_ld_base): Rename from pph_stream_read_ld_base.
	Update all users.
	(pph_in_ld_min): Rename from pph_stream_read_ld_min.
	Update all users.
	(pph_in_tree_vec): Rename from pph_stream_read_tree_vec.
	Update all users.
	(pph_in_qual_use_vec): Rename from pph_stream_read_qual_use_vec.
	Update all users.
	(pph_in_cxx_binding_1):  Rename from pph_stream_read_cxx_binding_1.
	Update all users.
	(pph_in_cxx_binding): Rename from pph_stream_read_cxx_binding.
	Update all users.
	(pph_in_class_binding): Rename from pph_stream_read_class_binding.
	Update all users.
	(pph_in_label_binding): Rename from pph_stream_read_label_binding.
	Update all users.
	(pph_in_binding_level): Rename from pph_stream_read_binding_level.
	Update all users.
	(pph_in_c_language_function): Rename from pph_stream_read_c_language_function.
	Update all users.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Joel Sherrill | 1 Jun 2011 07:01
Gravatar

Re: [build] Move Solaris 2 startup files to toplevel libgcc, revised

I am on travel and only doing email from my phone. Ralf and I had dinner together last night and he mentioned
not understanding some parts of the patch.  I won't be home until next week to actually test this. 

I guess hoping due diligence was used and knowing I may whine next week if it breaks RTEMS, do a visual double
check please on the RTEMS specific parts and commit it.  Either that or wait for a test report from me.

--joel

Rainer Orth <ro <at> CeBiTec.Uni-Bielefeld.DE> wrote:

>Paolo Bonzini <bonzini <at> gnu.org> writes:
>
>> On 05/30/2011 04:29 PM, Rainer Orth wrote:
>>>>> * Non-Solaris SPARC changes:
>>>>> >>
>>>>> >>     After I had moved sparc/sol2-c[in].asm to libgcc, I noticed that
>>>>> >>     despite the name a few non-Solaris targets uses those files, too:
>>>>> >>
>>>>> >>     sparc-*-elf*, sparc-*-rtems*, sparc64-*-elf*, sparc64-*-rtems*
>>>> >
>>>> >  Yes, I tried to untangle that, but the RTEMS folks complained so I had to
>>>> >  backpedal.  Note that this is also the case on the i386 side.
>>> Drats, I hadn't expected anything like this ;-(
>>>
>>> Here's the updated patch which takes care of this.  I've taken the
>>> liberty to rename gcc/config/i386/t-rtems-i386 to
>>> gcc/config/i386/t-rtems, following all other RTEMS makefile fragments.
>>> I'd be really grateful if the RTEMS maintainers could give it a whirl.
>>>
>>> Besides, I still need build and SPARC maintainer approval for the
(Continue reading)

Permalink | Reply | 1 comment |
headers
Basile Starynkevitch | 1 Jun 2011 07:52

PATCH: adding invoking_program to plugin_gcc_version


Hello All,

The attached patch to trunk 174518 adds a field invoking_program to the
plugin_gcc_version structure. It informs the plugin about the program
"cc1", "cc1plus", "lto1" using them.

######### gcc/ChangeLog entry ##########
2011-06-01  Basile Starynkevitch  <basile <at> starynkevitch.net>

	* gcc-plugin.h (struct plugin_gcc_version): Add invoking_program field.

	* toplev.c (general_init): Fill invoking_program field of gcc_version.

	* configure.ac: Ditto.

	* configure: Regenerate.
########################################

See http://gcc.gnu.org/ml/gcc/2011-06/msg00000.html & 
http://gcc.gnu.org/ml/gcc/2011-05/msg00324.html for why I believe it is useful.

Ok for trunk?

Regards.
--

-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
(Continue reading)

Permalink | Reply | 2 comments |
headers
Basile Starynkevitch | 1 Jun 2011 08:05

Re: PATCH: adding invoking_program to plugin_gcc_version

On Wed, 1 Jun 2011 07:52:48 +0200
Basile Starynkevitch <basile <at> starynkevitch.net> wrote:

> 
> Hello All,
> 
> The attached patch to trunk 174518 adds a field invoking_program to the
> plugin_gcc_version structure. It informs the plugin about the program
> "cc1", "cc1plus", "lto1" using them.

Wrong patch, here is a better one

######### gcc/ChangeLog entry ##########
2011-06-01  Basile Starynkevitch  <basile <at> starynkevitch.net>

	* gcc-plugin.h (struct plugin_gcc_version): Add invoking_program field.

	* configure.ac: Ditto.

	* configure: Regenerate.

	* plugin.c (initialize_plugins): Set invoking_program.

########################################

Ok if it bootstraps?

Cheers
--

-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
(Continue reading)

Permalink | Reply | 1 comment |

Gmane