RE: [RFC] Add middle end hook for stack red zone size
Quoting Jiangning Liu : Hi, One month ago, I sent out this RFC to *gcc-patches* mail list, but I didn't receive any response yet. So I'm forwarding this mail to *gcc* mail list. Can anybody here really give feedback to me? Well, I couldn't approve any patch, but I can point out some issues with your patch. First, it's missing a ChangeLog, and you don't state how you have tested it. And regarding the code in sched_analyze_1, I think you'll get false positives with alloca, and false negatives when registers are involved to compute offsets or to restore the stack pointer from. FWIW, I think generally blunt scheduling barriers should be avoided, and instead the dependencies made visible to the scheduler. E.g., I've been working with another architecture with a redzone, where at -fno-omit-frame-pointer, the prologue can put pretend_args into the redzone, then after stack adjustment and frame allocation, these arguments are accessed via the frame pointer. With the attached patchlet, alias analysis works for this situation too, so no blunt scheduling block is required. Likewise, with stack adjustments, they should not affect scheduling in general, but be considered to clobber the part of the frame that is being exposed to interrupt writes either before or after the adjustment. At the moment, each port that wants to have such selective scheduling blockages has to define a stack_adjust pattern with a memory clobber in a parallel, with a memref that shows the high water mark of possible interrupt stack writes. Prima facia it would seem convenient if you only had to tell the middle-end about the redzone size, and it could figure out the implicit clobbers when the stack is changed. However, when a big stack adjustment is being made, or the stack is realigned, or restored from the frame pointer / another register where it was saved due to realignment, the adjustment is not so obvious. I'm not sure if you can actually create an robust interface that's simpler to use than putting the right memory clobber in the stack adjust pattern. Note also that the redzone size can vary from function to function depending on ABI-altering attributes, in particular for interrupt functions, which can also have different incoming and outgoing redzone sizes. Plus, you can have an NMI / reset handler which can use the stack like an ordinary address register. 2009-09-23 Joern Rennecke * alias.c (base_alias_check): Allow for aliases between stack- and frame-pointer referenced memory. Index: alias.c === --- alias.c (revision 1646) +++ alias.c (revision 1647) @@ -1751,6 +1751,17 @@ base_alias_check (rtx x, rtx y, enum mac if (GET_CODE (x_base) != ADDRESS && GET_CODE (y_base) != ADDRESS) return 0; + /* If both are stack references, one via the stack pointer, the other via + the frame pointer, there can be an alias. + E.g.: gcc.c-torture/execute/20041113-1.c -O3 -g */ + if (GET_CODE (x_base) == ADDRESS + && (XEXP (x_base, 0) == stack_pointer_rtx + || XEXP (x_base, 0) == hard_frame_pointer_rtx) + && GET_CODE (y_base) == ADDRESS + && (XEXP (y_base, 0) == stack_pointer_rtx + || XEXP (y_base, 0) == hard_frame_pointer_rtx)) +return 1; + /* If one address is a stack reference there can be no alias: stack references using different base registers do not alias, a stack reference can not alias a parameter, and a stack reference
Re: [RFC] Remove -freorder-blocks-and-partition
Quoting Xinliang David Li : In xalancbmk, with the partition option, most of object files have nonzero size cold sections generated. The text size of the binary is increased to 3572728 bytes from 3466790 bytes. Profiling the program using the training input shows the following differences. With partitioning, number of executed branch instructions slightly increases, but itlb misses and icache load misses are significantly lower compared with the binary without partitioning. It is nice to have confirmation that for this benchmark, the optimization causes a speedup because it works as intended, however... dealII and bzip2 degrades about 1.4%. ... I think the question was more directed at what causes the performance degradation for these two benchmarks. If we could retain most of the speedups when the optimization works well but avoid most of the slowdown in the benchmarks that are currently hurt, we could improve the overall SPEC06 score. And hopefully, this would also be beneficial to other code.
RE: [RFC] Add middle end hook for stack red zone size
Hi, One month ago, I sent out this RFC to *gcc-patches* mail list, but I didn't receive any response yet. So I'm forwarding this mail to *gcc* mail list. Can anybody here really give feedback to me? Appreciate your help in advance! -Jiangning -Original Message- From: Ramana Radhakrishnan [mailto:ramana.radhakrish...@linaro.org] Sent: Tuesday, July 19, 2011 6:18 PM To: Jiangning Liu Cc: gcc-patc...@gcc.gnu.org; vmaka...@redhat.com; dje@gmail.com; Richard Henderson; Ramana Radhakrishnan Subject: Re: [RFC] Add middle end hook for stack red zone size 2011/7/19 Jiangning Liu : > > I see a lot of feedbacks on other posts, but mine is still with ZERO > response in the past 3 weeks, so I'm wondering if I made any mistake in my > process? Who can help me? It would be worth CC'ing the other relevant target maintainers as well to get some feedback since the patch touches ARM, x86 and Powerpc. I've added the maintainers for i386 and PPC to the CC list using the email addresses from the MAINTAINERS file. Thanks, Ramana > > Thanks, > -Jiangning > > -Original Message- > From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org] > On Behalf Of Jiangning Liu > Sent: Tuesday, July 05, 2011 8:32 AM > To: gcc-patc...@gcc.gnu.org; rgue...@gcc.gnu.org > Subject: RE: [RFC] Add middle end hook for stack red zone size > > PING... > > I just merged with the latest code base and generated new patch as attached. > > Thanks, > -Jiangning > >> -Original Message- >> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches- >> ow...@gcc.gnu.org] On Behalf Of Jiangning Liu >> Sent: 2011年6月28日 4:38 PM >> To: gcc-patc...@gcc.gnu.org >> Subject: [RFC] Add middle end hook for stack red zone size >> >> This patch is to fix PR38644, which is a bug with long history about >> stack red zone access, and PR30282 is correlated. >> >> Originally red zone concept is not exposed to middle-end, and back-end >> uses special logic to add extra memory barrier RTL and help the >> correct dependence in middle-end. This way different back-ends must >> handle red zone problem by themselves. For example, X86 target >> introduced function >> ix86_using_red_zone() to judge red zone access, while POWER introduced >> offset_below_red_zone_p() to judge it. Note that they have different >> semantics, but the logic in caller sites of back-end uses them to >> decide whether adding memory barrier RTL or not. If back-end >> incorrectly handles this, bug would be introduced. >> >> Therefore, the correct method should be middle-end handles red zone >> related things to avoid the burden in different back-ends. To be >> specific for PR38644, this middle-end problem causes incorrect >> behavior for ARM target. >> This patch exposes red zone concept to middle-end by introducing a >> middle-end/back-end hook TARGET_STACK_RED_ZONE_SIZE defined in >> target.def, and by default its value is 0. Back-end may redefine this >> function to provide concrete red zone size according to specific ABI >> requirements. >> >> In middle end, scheduling dependence is modified by using this hook >> plus checking stack frame pointer adjustment instruction to decide >> whether memory references need to be all flushed out or not. In >> theory, if TARGET_STACK_RED_ZONE_SIZE is defined correctly, back-end >> would not be required to specially handle this scheduling dependence >> issue by introducing extra memory barrier RTL. >> >> In back-end, the following changes are made to define the hook, >> 1) For X86, TARGET_STACK_RED_ZONE_SIZE is redefined to be >> ix86_stack_red_zone_size() in i386.c, which is an newly introduced >> function. >> 2) For POWER, TARGET_STACK_RED_ZONE_SIZE is redefined to be >> rs6000_stack_red_zone_size() in rs6000.c, which is also a newly >> defined function. >> 3) For ARM and others, TARGET_STACK_RED_ZONE_SIZE is defined to be >> default_stack_red_zone_size in targhooks.c, and this function returns >> 0, which means ARM eabi and others don't support red zone access at all. >> >> In summary, the relationship between ABI and red zone access is like >> below, >> >> - >> | ARCH | ARM | X86 |POWER | others | >> |--|---|---|---|| >> |ABI | EABI | MS_64 | other | AIX | V4 || >> |--|---|---|---||--|| >> | RED ZONE | No | YES | No | YES | No | No | >> |--|---|---|---||--|| >> | RED ZONE SIZE| 0 | 128 | 0 |220/288 | 0 |0 | >> - >> >> Thanks, >> -Jiangning > > > >
Re: [RFC] Remove -freorder-blocks-and-partition
In xalancbmk, with the partition option, most of object files have nonzero size cold sections generated. The text size of the binary is increased to 3572728 bytes from 3466790 bytes. Profiling the program using the training input shows the following differences. With partitioning, number of executed branch instructions slightly increases, but itlb misses and icache load misses are significantly lower compared with the binary without partitioning. David With partition: - 53654937239 branches 306751458 L1-icache-load-misses 8146112 iTLB-load-misses Without partition: - 52348639025 branches 454417666 L1-icache-load-misses 14470953 iTLB-load-misses On Mon, Jul 25, 2011 at 3:23 AM, Paolo Bonzini wrote: > On 07/25/2011 06:42 AM, Xinliang David Li wrote: >> >> FYI the performance impact of this option with SPEC06 (built with >> google_46 compiler and measured on a core2 box). The base line number >> is FDO, and ref number is FDO + reorder_with_partitioning. >> >> xalancbmk improves> 3.5% >> perlbench improves> 1.5% >> dealII and bzip2 degrades about 1.4%. >> >> Note the partitioning scheme is not tuned at all -- there is not even >> a tunable parameter to play with. > > Did you check what is pushed down to the cold section in these cases? > > Paolo >
[PATCH] for Re: 404 Error on Page
On Tue, 26 Jul 2011, Gerald Pfeifer wrote: >> # Viet Nam, HoChiMinh: http://mirror-fpt-telecom.fpt.net/gcc/, thanks to >> Minh Vu Tong (mirror at fpt dot net) >> >> is messed up. I repeatedly get a 404 error. > Minh Vu Tong, or other admins at fpt.net, is this a temporary situation > or shall I remove your mirror from our list? Turns out that that contact address bounces, so I'm going ahead and remove the mirror. Applied. Gerald Index: mirrors.html === RCS file: /cvs/gcc/wwwdocs/htdocs/mirrors.html,v retrieving revision 1.209 diff -u -r1.209 mirrors.html --- mirrors.html26 Apr 2011 20:23:04 - 1.209 +++ mirrors.html25 Jul 2011 23:04:52 - @@ -53,7 +53,6 @@ UK, London: http://gcc-uk.internet.bs";>http://gcc-uk.internet.bs, thanks to Internet.bs (info at internet dot bs) US, Phoenix: http://fileboar.com/gcc/";>fileboar.com, thanks to Grigory Rayskin (rayskin73 at gmail dot com) US, Tampa: http://mirrors-us.seosue.com/gcc/";>http://mirrors-us.seosue.com/gcc/, thanks to Peter Vrzak (petervrzak at gmail dot com) -Viet Nam, HoChiMinh: http://mirror-fpt-telecom.fpt.net/gcc/";>http://mirror-fpt-telecom.fpt.net/gcc/, thanks to Minh Vu Tong (mirror at fpt dot net) If you wish to host a new mirror site, please contact
Re: 404 Error on Page
On Fri, 22 Jul 2011, Ahmed Jaffer wrote: > http://gcc.gnu.org/mirrors.html > > your Vietnam mirror > > # Viet Nam, HoChiMinh: http://mirror-fpt-telecom.fpt.net/gcc/, thanks to Minh > Vu Tong (mirror at fpt dot net) > > is messed up. I repeatedly get a 404 error. Thanks for the report! Minh Vu Tong, or other admins at fpt.net, is this a temporary situation or shall I remove your mirror from our list? Gerald
Re: Linemap and pph
Alright, so after looking even more at the linemap code, here is what I'm thinking now: So the main problem is: with the linemap logic is that linemap_line_start adds a new table entry if line_delta < 0 (I don't understand why this is needed, my assumption is that it is because the rest of the logic depends on set->highest_location, thus we want to make sure we are higher than the highest so far? can someone clarify why we need this?) My solution: I will add a boolean flag to linemap_line_start's parameters, allowEarlierStartLineStart, which when true, will not create a new entry in the line_table even if the line_delta < 0. Instead of relying on highest_location to find the current line's source location, it will use the start_location and add to it the delta between to_line and map->to_line). I will also add a new linemap function, linemap_position_for_line_and_column, which will be just like linemap_position_for_column, except that it won't assume the highest_line in the set is the one we are currently on (this function will thus allow us to get a source_location without depending on the current assumptions on the order these functions are called in). This solution would not modify the actual final result of the entries, at the end of parsing, as far as I understand (I would also of course only use this new flag in the call from lto_input_location (which we use in pph to get our source_location from the streamed expanded_location)) Let me know what you think, Gabriel
Re: conversion: immediate-value -> memory ref
Hagen Meyer writes: > Problem: no immediate-values are supported in the instructions. > How can I tell the compiler to put all immediates into the memory, and > use the corresponding reference instead of the value itself? See the TARGET_LEGITIMATE_CONSTANT_P target hook. See also ASM_OUTPUT_POOL_PROLOGUE and friends. Ian
Re: hash signature of cc1 etc....?
Hi
Le 23 juil. 2011 à 07:45, Basile Starynkevitch a écrit :
> On Fri, 22 Jul 2011 15:12:36 -0700
> Ian Lance Taylor wrote:
>
>> Basile Starynkevitch writes:
>>
>>> Should we add an option to the gcc driver which would print such checksums?
>>
>> I'm not quite sure what checksums you want.
>>
>> Suppose you just do
>>
>> md5sum `gcc --print-file-name=cc1`
>>
>> ?
>>
>> That will give you a checksum without gcc going to the trouble of
>> generating it.
>
>
> What about the other files. (lto1, cc1plus...). On my Debian/Sid,
> % gcc --print-file-name=cc1
> /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/cc1
>
> But
> % ls -F /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/
> 32/ crtprec80.o libgcj-tools.so@libquadmath.a
> cc1* ecj1*libgcj.so@ libquadmath.so@
> cc1plus* gengtype* libgcj.spec libssp_nonshared.a
> collect2* gtype.statelibgcj_bc.solibstdc++.a
> crtbegin.o include/ libgcov.a libstdc++.so@
> crtbeginS.oinclude-fixed/ libgij.so@ libsupc++.a
> crtbeginT.ojc1* libgomp.a lto-wrapper*
> crtend.o jvgenmain* libgomp.so@ lto1*
> crtendS.o libgcc.a libgomp.specplugin/
> crtfastmath.o libgcc_eh.aliblto_plugin.so@
> crtprec32.olibgcc_s.so@ liblto_plugin.so.0@
> crtprec64.olibgcc_s_32.so@liblto_plugin.so.0.0.0
>
>
> How can I know which of the above files have some influence on the behavior
> of GCC
> plugins? (This is not true of all, crtbegin.o don't, and I would think that
> gengtype
> don't neither, because I believe that its observable behavior changes only
> from 4.6 to
> 4.7, but not much from 4.6.0 to 4.6.1).
Plugins only depends on all the header files (gtype.state might also be useful)
that GCC allows plugins to see. After all, it's the only thing that's needed to
build a plugin. If headers didn't changed but a .o file did because of some
patch, you won't see any change when rebuilding the whole plugin (as plugin
won't see them). Plugins are nothing more than shared object build with a bunch
of header files. So you just need to correctly write header dependencies in
your plugin Makefile and it will just work as needed.
Anyway, GCC plugin API brings you plugin_default_version_check which performs
checks on revision number + build configuration. By using this check on
runtime, you can be assured that the GCC that run the plugin fits the one that
build it.
Romain Geissler
>
> I was suggesting adding some way to get the checksums of only the relevant
> files.
>
> Regards.
> --
> Basile STARYNKEVITCH http://starynkevitch.net/Basile/
> email: basilestarynkevitchnet mobile: +33 6 8501 2359
> 8, rue de la Faiencerie, 92340 Bourg La Reine, France
> *** opinions {are only mine, sont seulement les miennes} ***
Re: Linemap and pph
On Sat, Jul 23, 2011 at 8:51 AM, Dodji Seketeli wrote: > Gabriel Charette a écrit: > >>> Gabriel> @tromey: I hear you are the person in the know when it comes down >>> to >>> Gabriel> linemaps, do you have any hint on how we could rebuild a valid >>> Gabriel> line_table given we are obtaining the bindings from the last one in >>> Gabriel> the file to the first one (that is, using pph (pre-parsed headers) >>> Gabriel> where we are trying to restore a cached version of the parser state >>> Gabriel> for a header)? >>> >>> Can you not just serialize the line map when creating the PPH? >>> >> >> We were wondering about that, the problem we thought is that a pph can >> be loaded from anywhere in many different C files (which would >> generate a different linemap entry in each case I think?). > > Just to make sure I understand, a given header included from two > different main C files with two different sets of macro context would > yield two macro maps with different contents anyway. So I would believe > that these would yield two different pph, one for each C file. Is that > correct? > Before using a pph, we make sure the current macro context is the same as the one in which it was originally compiled (as far as what that header is using from that context). So yes, sometimes we have different pph for different C files, but it's very possible to use the same pph for different includes in independent C files. > For the cases where the same pph could be loaded from two different main > CUs, I'd say that in the context of a given main CU being parsed, loading > the PPH and its associated serialized line map would yield a new line > map to be inserted into the struct linemaps of the current CU. > > Then, not only should the source_locations encoded by that new > de-serialized line map be rewritten (probably by modifying things like > struct linemap::to_line and struct linemap::included_from, if need be) > to fit into the source_location space of the line map set carried by the > struct linemaps of the current main CU being parsed, but the > source_locations carried by the tokens present inside the pph must also > be changed to look as if they were yielded by the newly rewritten line > map. This is what could look expensive at first sight. > Right this is one of the option, but as you say, potentially an expensive change. > Wouldn't that address the issue of a given pph loaded by multiple main C > files? > If it works, yes, I think. >> If there was a way to serialize the linemap entries from the LC_ENTER >> entry for the header file to the LC_LEAVE (i.e. ignoring builtins, >> command line, etc.) > > I believe all the builtins have the same source_location, which is the > BUILTIN_LOCATION constant. As for command line options, I believe they > get the location UNKNOWN_LOCATION. So I would think these should not be > a problem when de-serializing the line map. > Right, but no point serializing them only to filter them on input.
Re: [RFC] Remove -freorder-blocks-and-partition
On Mon, Jul 25, 2011 at 3:23 AM, Paolo Bonzini wrote: > On 07/25/2011 06:42 AM, Xinliang David Li wrote: >> >> FYI the performance impact of this option with SPEC06 (built with >> google_46 compiler and measured on a core2 box). The base line number >> is FDO, and ref number is FDO + reorder_with_partitioning. >> >> xalancbmk improves> 3.5% >> perlbench improves> 1.5% >> dealII and bzip2 degrades about 1.4%. >> >> Note the partitioning scheme is not tuned at all -- there is not even >> a tunable parameter to play with. > > Did you check what is pushed down to the cold section in these cases? I have not done any analysis on them . David > > Paolo >
Re: conversion: immediate-value -> memory ref
On Mon, Jul 25, 2011 at 11:08 AM, Hagen Meyer wrote: > But HOW can I force the operand into memory? > I.e. "force_const_to_memref" needs to be defined somehow. > Any hints? varasm.c:force_const_mem() ? - David
conversion: immediate-value -> memory ref
Hi,
I'm trying to port GCC to a simple processor (used only for academic
purposes, yet).
Problem: no immediate-values are supported in the instructions.
How can I tell the compiler to put all immediates into the memory, and
use the corresponding reference instead of the value itself?
so, instead of
move REG,5
I would like to have
move REG,const5
…
; and somewhere else
const5: .word 5
My approach would be, to use a define_expand statement like this:
(define_expand "movhi"
[(set (match_operand:HI 0 "general_operand" "")
(match_operand:HI 1 "general_operand" ""))]
""
"
{
/* we are not able to use immediates, so put them to memory */
if (CONST_INT_P (operands[1]))
operands[1] = force_const_to_memref (HImode, operands[1]);
}")
But HOW can I force the operand into memory?
I.e. "force_const_to_memref" needs to be defined somehow.
Any hints?
Thanks a lot!
Hagen
Re: Copyright Assignment forms
On Mon, Jul 25, 2011 at 3:40 AM, Thomas Henlich wrote: > Hi, > > I would like to contribute code to GFortran, starting with some work > on http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906, but maybe more > in the future. > > Please could you send me the necessary forms for copyright assignment > that I need to fill out. Sent off list. - David
Re: write after approval status
On Mon, Jul 25, 2011 at 01:05:17PM +0200, Pierre Vittet wrote:
> Hello,
>
> I might need to commit on the MELT branch in the next weeks, however
> Basile Starynkevitch which is the maintainer for this branch will
> not be able to commit my patchs as he will be on holliday.
>
> So, I request a Write after approval status, as from what I have
> understood I need this status even to have the ability to commit in
> a GCC branch different from the trunk. If it is possible (but I
> guess it is not) I could simply have a write approval limited to the
> MELT branch.
>
> If I get write after approval status, It will not change my way to
> send patch to the trunk, as I need to get a positif answer from a
> reviewer before sending it.
> From, the MELT branch, Basile agrees to allow me to commit patch, he
> will also be able to review my change when he comes back and to
> revert if it is really necessary. This ability to commit on the MELT
> branch is quite important for me, in order to complete my GSOC
> project.
>
> Here are some links to the patchs I already proposed (and were accepted):
>
> [PATCH] c-pragma: adding a data field to pragma_handler:
> http://gcc.gnu.org/ml/gcc-patches/2011-06/msg00067.html
> which was finally updated in:
> http://gcc.gnu.org/ml/gcc-patches/2011-06/msg00854.html
>
> [PATCH, MELT] add dominance functions
> http://gcc.gnu.org/ml/gcc-patches/2011-05/msg01306.html
>
> [PATCH, MELT] Add PRE_GENERICIZE callback support in MELT
> http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01311.html
>
> [PATCH, MELT] correct meltgc_read_from_val without location
> http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01888.html
>
> [PATCH, MELT] pragma support in MELT
> http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01861.html
>
> [PATCH, MELT] fix useless forcing of GCC garbage collector
> http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00648.html
>
> [PATCH, MELT] correcting path error in the Makefile.in:
> http://gcc.gnu.org/ml/gcc-patches/2011-05/msg01232.html
>
I do hope that Pierre Vittet will get the account on GCC svn to be able to
write into the MELT branch;
First, I want him to (and I trust him enough to) be able to commit his patches
into the MELT branch.
And second, I want also him to merge regularily the trunk into the MELT branch,
as I do (usually twice a week).
So I would be very grateful if Pierre did got an svn write access to GCC.
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
write after approval status
Hello, I might need to commit on the MELT branch in the next weeks, however Basile Starynkevitch which is the maintainer for this branch will not be able to commit my patchs as he will be on holliday. So, I request a Write after approval status, as from what I have understood I need this status even to have the ability to commit in a GCC branch different from the trunk. If it is possible (but I guess it is not) I could simply have a write approval limited to the MELT branch. If I get write after approval status, It will not change my way to send patch to the trunk, as I need to get a positif answer from a reviewer before sending it. From, the MELT branch, Basile agrees to allow me to commit patch, he will also be able to review my change when he comes back and to revert if it is really necessary. This ability to commit on the MELT branch is quite important for me, in order to complete my GSOC project. Here are some links to the patchs I already proposed (and were accepted): [PATCH] c-pragma: adding a data field to pragma_handler: http://gcc.gnu.org/ml/gcc-patches/2011-06/msg00067.html which was finally updated in: http://gcc.gnu.org/ml/gcc-patches/2011-06/msg00854.html [PATCH, MELT] add dominance functions http://gcc.gnu.org/ml/gcc-patches/2011-05/msg01306.html [PATCH, MELT] Add PRE_GENERICIZE callback support in MELT http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01311.html [PATCH, MELT] correct meltgc_read_from_val without location http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01888.html [PATCH, MELT] pragma support in MELT http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01861.html [PATCH, MELT] fix useless forcing of GCC garbage collector http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00648.html [PATCH, MELT] correcting path error in the Makefile.in: http://gcc.gnu.org/ml/gcc-patches/2011-05/msg01232.html Pierre Vittet
Re: [RFC] Remove -freorder-blocks-and-partition
On 07/25/2011 06:42 AM, Xinliang David Li wrote: FYI the performance impact of this option with SPEC06 (built with google_46 compiler and measured on a core2 box). The base line number is FDO, and ref number is FDO + reorder_with_partitioning. xalancbmk improves> 3.5% perlbench improves> 1.5% dealII and bzip2 degrades about 1.4%. Note the partitioning scheme is not tuned at all -- there is not even a tunable parameter to play with. Did you check what is pushed down to the cold section in these cases? Paolo
GCC build time using bash vs. dash
Hi! When recently fixing a GCC configury bug uncovered by using dash for /bin/sh, we wondered which build-time benefits the use of dash would actually bring. kepler is a Xen domU on a AMD Athlon II X2 215 with 2700 MHz, the domU has 1 GiB of RAM, and is running Debian GNU/Linux testing x86. Debian packages bash 4.1-3, dash 0.5.5.1-7.4. coulomb is a AMD Athlon XP with 1466 MHz, has 1 GiB of RAM, and is running Debian GNU/Hurd unstable x86. Debian packages bash 4.1-3+hurd.1, dash 0.5.5.1-7.4. kepler coulomb bash 2 h 45 min 10 h 55 min dash 2 h 35 min 10 h 50 min This data is from one iteration only (I did not repeat the experiment), but both systems have been idle apart from the GCC build. The build was essentially a native ``configure && make'', based on GCC Git sources, master branch, 7c9f953a01d23c6b6885dc908d5b1dba8009efd4 (2011-07-18), plus a few patches (minor to this experiment). Grüße, Thomas pgpJ6eFldZyZm.pgp Description: PGP signature
Copyright Assignment forms
Hi, I would like to contribute code to GFortran, starting with some work on http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906, but maybe more in the future. Please could you send me the necessary forms for copyright assignment that I need to fill out. Regards, Thomas.
