Right -- I missed Richard's previous email regarding the options.
Thanks,
David
On Fri, Aug 27, 2010 at 5:21 PM, Andrew Pinski wrote:
> On Fri, Aug 27, 2010 at 5:12 PM, Xinliang David Li wrote:
>> Briefly looked at it -- the trunk gcc also regresses a lot compared to
>> the binary you attached
On Fri, Aug 27, 2010 at 5:12 PM, Xinliang David Li wrote:
> Briefly looked at it -- the trunk gcc also regresses a lot compared to
> the binary you attached. (To match your binary, also added
> -mfpmath=387 -m32 options)
>
> Two problems:
>
> 1) more register spills in the trunk version -- the old
Briefly looked at it -- the trunk gcc also regresses a lot compared to
the binary you attached. (To match your binary, also added
-mfpmath=387 -m32 options)
Two problems:
1) more register spills in the trunk version -- the old compiler seems
more effective in using fp stack registers;
2) the comp
Another main thing missing is to consider profile information (if
available) so that most frequent cases can be peeled out.
David
On Fri, Aug 27, 2010 at 8:03 AM, Richard Guenther
wrote:
> On Fri, Aug 27, 2010 at 4:47 PM, Ian Lance Taylor wrote:
>> "Paulo J. Matos" writes:
>>
>>> In the first
On Fri, Aug 27, 2010 at 8:37 PM, Hongtao wrote:
> On 08/27/10 14:29, Richard Guenther wrote:
>> On Fri, Aug 27, 2010 at 8:24 PM, Hongtao wrote:
>>
>>> On 08/27/10 12:35, Richard Guenther wrote:
>>>
On Fri, Aug 27, 2010 at 5:27 PM, Hongtao wrote:
> Hi all,
>
> I have in
On 08/27/10 14:29, Richard Guenther wrote:
> On Fri, Aug 27, 2010 at 8:24 PM, Hongtao wrote:
>
>> On 08/27/10 12:35, Richard Guenther wrote:
>>
>>> On Fri, Aug 27, 2010 at 5:27 PM, Hongtao wrote:
>>>
>>>
Hi all,
I have instrumented a function call like foo(&a,&b) int
On Fri, Aug 27, 2010 at 8:24 PM, Hongtao wrote:
> On 08/27/10 12:35, Richard Guenther wrote:
>> On Fri, Aug 27, 2010 at 5:27 PM, Hongtao wrote:
>>
>>> Hi all,
>>>
>>> I have instrumented a function call like foo(&a,&b) into the gimple SSA
>>> representation (gcc-4.5) and the consequent optimizati
On 08/27/10 12:35, Richard Guenther wrote:
> On Fri, Aug 27, 2010 at 5:27 PM, Hongtao wrote:
>
>> Hi all,
>>
>> I have instrumented a function call like foo(&a,&b) into the gimple SSA
>> representation (gcc-4.5) and the consequent optimizations can not pass
>> my instrumented code. The back tra
Basile Starynkevitch writes:
> My impression is that s->u.s.line.file usually happens to have the same
> offset (at least on GNU/Linux/AMD64=x86_64) as
> s->u.param_struct.param[0] and that for every type concerned by
> output_type_enum its param[0] subfield happens to be non-null. This
> explai
On Fri, 2010-08-27 at 17:25 +0300, Laurynas Biveinis wrote:
> 2010/8/27 :
> > We recompiled GCC-trunk r162692 with the following modification :
> >
> > In function output_type_enum of gcc/gengtype.c, we replaced
> >
> > - if (s->kind == TYPE_PARAM_STRUCT && s->u.s.line.file != NULL)
> > + if (s-
On Fri, Aug 27, 2010 at 5:27 PM, Hongtao wrote:
> Hi all,
>
> I have instrumented a function call like foo(&a,&b) into the gimple SSA
> representation (gcc-4.5) and the consequent optimizations can not pass
> my instrumented code. The back traces are as followings. The error
> occurred when the pa
Hello Prof. Khedker,
Your tutorial would be very useful. I am trying my best
to attend the Summit, this being an important motivator.
Thank you.
Sincerely,
Anmol P. Paralkar
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf
Of
> Uday Khedker
Hi all,
I have instrumented a function call like foo(&a,&b) into the gimple SSA
representation (gcc-4.5) and the consequent optimizations can not pass
my instrumented code. The back traces are as followings. The error
occurred when the pass dse tried to test if the call I inserted may use
a memory
On Fri, 2010-08-27 at 17:09 +0200, Richard Guenther wrote:
> On Fri, Aug 27, 2010 at 5:02 PM, Corey Kasten
> wrote:
> > On Fri, 2010-08-27 at 06:50 -0700, Nathan Froyd wrote:
> >> On Fri, Aug 27, 2010 at 09:44:25AM -0400, Corey Kasten wrote:
> >> > I find that the executable compiled on system A r
When doing native bootstraps things are nice and easy ... the target
spec definitions are also appropriate for the host.
===
I've been doing some canadian X-s (specifically darwin 9 => darwin 7).
So, ... when doing B == H != T the specs might need to be different
from B != H == T (or B
On Fri, Aug 27, 2010 at 5:02 PM, Corey Kasten
wrote:
> On Fri, 2010-08-27 at 06:50 -0700, Nathan Froyd wrote:
>> On Fri, Aug 27, 2010 at 09:44:25AM -0400, Corey Kasten wrote:
>> > I find that the executable compiled on system A runs faster (on both
>> > systems) than the executable compiled on sys
On Fri, Aug 27, 2010 at 4:47 PM, Ian Lance Taylor wrote:
> "Paulo J. Matos" writes:
>
>> In the first case, it generates a binary tree, and in the second two
>> jump tables. The jump tables solution is much more elegant (at least
>> in our situation), generating less code and being faster.
>> Now
On Fri, Aug 27, 2010 at 3:47 PM, Ian Lance Taylor wrote:
>
> I don't know of any specific reason not to look for clusters of switch
> cases. The main issue would be the affect on compilation time. If you
> can do it with an algorithm which is linear in the number of cases, then
> I think it woul
On Fri, 2010-08-27 at 06:50 -0700, Nathan Froyd wrote:
> On Fri, Aug 27, 2010 at 09:44:25AM -0400, Corey Kasten wrote:
> > I find that the executable compiled on system A runs faster (on both
> > systems) than the executable compiled on system B (on both system), by a
> > factor about approximately
"Paulo J. Matos" writes:
> In the first case, it generates a binary tree, and in the second two
> jump tables. The jump tables solution is much more elegant (at least
> in our situation), generating less code and being faster.
> Now, what I am wondering is the reason why GCC doesn't try to cluste
jeremie.salvu...@free.fr writes:
> While hacking on gengtype with Basile, we noticed a strange piece of code at
> line 2539 in gcc/gengtype.c r162692
>
> static void
> output_type_enum (outf_p of, type_p s)
> {
> if (s->kind == TYPE_PARAM_STRUCT && s->u.s.line.file != NULL) /* Strange
> code @
2010/8/27 :
> We recompiled GCC-trunk r162692 with the following modification :
>
> In function output_type_enum of gcc/gengtype.c, we replaced
>
> - if (s->kind == TYPE_PARAM_STRUCT && s->u.s.line.file != NULL)
> + if (s->kind == TYPE_PARAM_STRUCT && s->u.param_struct.line.file != NULL)
>
> And
> In function output_type_enum of gcc/gengtype.c, we replaced
>
> - if (s->kind == TYPE_PARAM_STRUCT && s->u.s.line.file != NULL)
> + if (s->kind == TYPE_PARAM_STRUCT && s->u.param_struct.line.file !=
> NULL)
>
> And Gengtype works like before with c,c++, lto enabled.
>
> Do you think we have
We recompiled GCC-trunk r162692 with the following modification :
In function output_type_enum of gcc/gengtype.c, we replaced
- if (s->kind == TYPE_PARAM_STRUCT && s->u.s.line.file != NULL)
+ if (s->kind == TYPE_PARAM_STRUCT && s->u.param_struct.line.file != NULL)
And Gengtype works like befo
On Fri, Aug 27, 2010 at 09:44:25AM -0400, Corey Kasten wrote:
> I find that the executable compiled on system A runs faster (on both
> systems) than the executable compiled on system B (on both system), by a
> factor about approximately 4 times. I have attempted to play with the
> GCC optimizer fla
On Fri, Aug 27, 2010 at 6:44 AM, Corey Kasten
wrote:
> Hello all,
>
> I have two computers with two different versions of GCC. Otherwise the
> two systems have identical hardware. I have a processor and memory
> intensive benchmark program which I compile on both systems and I cannot
> understand
Hello all,
I have two computers with two different versions of GCC. Otherwise the
two systems have identical hardware. I have a processor and memory
intensive benchmark program which I compile on both systems and I cannot
understand why the system with older GCC version compiles faster code.
Sys
Hi,
I have been analysing the gcc4.4 code due to the way it's handling:
1 extern void f(const char *);
2 extern void g(int);
3
4 #define C(n) case n: f(#n); break
5
6 void g(int n)
7 {
8 switch(n)
9 {
10 C(0); C(1); C(2); C(3); C(4); C(5); C(6); C(7); C(8); C(9);
11
"Or can a type have a kind TYPE_PARAM_STRUCT and only have s->u.s valid? It
might be related to the code in new_structure near line 638 of gengtype.c
which sets ls->kind = TYPE_LANG_STRUCT."
Forget about this sentence, Basile messed up TYPE_PARAM_STRUCT &
TYPE_LANG_STRUCT (and is typing this).
2010/8/27 :
> We think that the enum type_kind discriminates fields union in struct type.
> So for TYPE_PARAM_STRUCT we believe that
> the param_struct field of union u inside struct type is used. If this is
> true, the test s->u.s.line.file != NULL is meaningless when s->kind ==
> TYPE_PARAM_
Hello all,
While hacking on gengtype with Basile, we noticed a strange piece of code at
line 2539 in gcc/gengtype.c r162692
static void
output_type_enum (outf_p of, type_p s)
{
if (s->kind == TYPE_PARAM_STRUCT && s->u.s.line.file != NULL) /* Strange code
@@*/
{
oprintf (of, ", gt_e_
We have had a long term plan (which has not fructified until now) of
implementing a static analysis for improving garbage collection. Our
paper in TOPLAS (http://portal.acm.org/citation.cfm?id=1290521) describes
our early work. The main bottle neck for our purpose is a good pointer
analysis and we
32 matches
Mail list logo
