On Wed, Nov 4, 2009 at 4:36 PM, Dave Korn
wrote:
> Justin Mattock wrote:
>> here's what I did:
>> valgrind --tool=memcheck --leak-check=full -v make -f client.mk build
>
>> ==4072== LEAK SUMMARY:
>
>> I'll try out gdb, and more of valgrind.
>
> Yep, that doesn't tell us a lot in its default mode
On 11/04/09 10:14, Vladimir Makarov wrote:
I am agree with Jeff. It is hard to understand what you are doing
without the architecture knowledge and some macro values in your port
(IRA_COVER_CLASSES, MEMORY_MOVE_COST, and REGISTER_MOVE_COST).
I'd also add that besides right macro value defin
Justin Mattock wrote:
> here's what I did:
> valgrind --tool=memcheck --leak-check=full -v make -f client.mk build
> ==4072== LEAK SUMMARY:
> I'll try out gdb, and more of valgrind.
Yep, that doesn't tell us a lot in its default modes. I'm not a valgrind
expert but it looks from the docs lik
> > + if (verbose) {
> > + task_lock(p);
>
> We need to be careful with which locks we take on the oom-killer path,
> because it can be called by code which already holds locks. But I
> expect task_lock() will be OK.
Sure.
task_lock() is already used various oom path. I think this is
On Wed, Nov 4, 2009 at 10:30 PM, Andrew Pinski wrote:
> On Wed, Nov 4, 2009 at 1:20 PM, Toon Moene wrote:
>> You don't happen to recall the bug number ?
>
> It might be related to PR 41735 which I noticed when looking at the
> generated assembly and trying to compare 4.5 to 4.4.
Yes indeed. Hon
On Wed, Nov 4, 2009 at 1:20 PM, Toon Moene wrote:
> You don't happen to recall the bug number ?
It might be related to PR 41735 which I noticed when looking at the
generated assembly and trying to compare 4.5 to 4.4.
Thanks,
Andrew Pinski
here's what I did:
valgrind --tool=memcheck --leak-check=full -v make -f client.mk build
e2 -march=core2 -O2 -pipe -fomit-frame-pointer -DMOZILLA_CLIENT
-include ./js-confdefs.h -Wp,-MD,.deps/jsxml.pp
/home/justin/LFS/firefox/mozilla-1.9.2/js/src/jsxml.cpp
{standard input}: Assembler messages:
Richard Guenther wrote:
I think the underlying issue is
phtask/41(-1) @0x7fd198c35100 availability:local 26416 time, 4268
benefit 4541 size, 880 benefit 480 bytes stack usage reachable body
local finalized inlinable
called by:
phcall/33(-1) @0x7fd198c33a00 availability:local 8281 time, 972
ben
I've checked in patches to the microblaze branch
to bring it into sync with gcc-4.4.2. This has been
tagged with microblaze-4.4.2.
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Dave Korn wrote:
Justin Mattock wrote:
O.k. here is the info from dmesg(with the patch added)
and what -fmem-report:
I don't know how to read the oom dmesg, but as to the -fmem-report:
Memory still allocated at the end of the compilation process
Size AllocatedUsed
On 11/04/09 10:52, Ian Bolton wrote:
Hi Jeff,
From an empirical perspective, the value of your patch is hard to
determine at this stage - one benchmark improved about 0.5% but others
have marginally regressed.
It's a hack, no doubt about it. Your results are about what I expected,
a few t
Justin Mattock wrote:
> O.k. here is the info from dmesg(with the patch added)
> and what -fmem-report:
I don't know how to read the oom dmesg, but as to the -fmem-report:
> Memory still allocated at the end of the compilation process
> Size AllocatedUsedOverhead
> Total 72
On Wed, Nov 4, 2009 at 8:19 PM, Toon Moene wrote:
> Jan,
>
> I had some time to study the example I sent you a couple of weeks ago.
>
> According to visible inspection of the source code, there are 5 functions
> (subroutines in Fortran parlance) that are called once:
>
> MAIN calls
> HLPROG call
Jan,
I had some time to study the example I sent you a couple of weeks ago.
According to visible inspection of the source code, there are 5
functions (subroutines in Fortran parlance) that are called once:
MAIN calls
HLPROG calls
GEMINI calls
SL2TIM calls
PHCALL calls
PHTASK
I.e., the last
I've just found (when I wanted to run a reghunt, which is way faster
with hg than with svn) that the mercurial mirror of svn mainline hasn't
been updated since September 10th. Is there any chance that this mirror
can be revived?
Thanks.
Rainer
--
Hi Jeff,
From an empirical perspective, the value of your patch is hard to
determine at this stage - one benchmark improved about 0.5% but others
have marginally regressed.
From an intellectual perspective, however, your patch is clearly a Good
Thing. If I am understanding correctly, your aim is
Jeff Law wrote:
On 11/03/09 09:29, Ian Bolton wrote:
Hi again, Vladimir,
I am pleased to report some performance improvements after altering
ira-costs.c. A key benchmark for us has improved by 5%.
Specifically, in record_reg_classes(), after the alt_cost has been
calculated and it will be app
Paul Edwards wrote:
> The QI must be a signed char, and thus rejecting any value greater than 127.
> As you can see, I changed it to SI, which, with the constraints and tests
> in place, should be fine.
Ah, OK. That would explain it.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Lin
Jean Christophe Beyler writes:
>> You can force your writes to the stack to not be removed by making
>> them use UNSPEC_VOLATILE. You would write special define_insns for
>> this.
>
> Is there an architecture port that has done this already ?
No, because, when given the choice, gcc prefers fast
On Wed, Nov 4, 2009 at 7:45 AM, Dave Korn
wrote:
> Justin P. Mattock wrote:
>
>> I can try, only issue I have is I don't
>> use a distro, so building anything requires me
>> to hand compile it
>
> Oh, ouch!
>
I know.. I'm a horror for optimization
>> (hopefully not difficult for gdb).
>
> Inde
On 11/04/2009 05:34 AM, Mohamed Shafi wrote:
Load-store uses 32bits. Sign extension happens automatically. So i
have choosen INT_MODE (RI, 5) and copied movsi and renamed it to
movri. I have also specified that RImode need only one register.
This isn't going to work. In order to get correct co
On Wed, Nov 04, 2009 at 11:24:34AM -0500, Jean Christophe Beyler wrote:
> However, I've been going through the first step : running GDB, setting
> a break-point and doing a continue to see what I get and try to get
> the information right for O3 too.
>
> In O0, I get:
> Breakpoint @@ 1, foo (a=4,
> You can force your writes to the stack to not be removed by making
> them use UNSPEC_VOLATILE. You would write special define_insns for
> this.
Is there an architecture port that has done this already ?
> Not to miss the obvious, note that this will hurt optimization.
> However, if you need to
Justin P. Mattock wrote:
> I can try, only issue I have is I don't
> use a distro, so building anything requires me
> to hand compile it
Oh, ouch!
> (hopefully not difficult for gdb).
Indeed, hopefully not.
> So give me some time on this and I'll see if I can get this up
> and running, and
On Wed, 4 Nov 2009 18:32:16 +0900 (JST) KOSAKI Motohiro
wrote:
> > It would help if the oom-killer were to print some information about
> > the oom-killed process's memory footprint.
> >
>
>
> How about this?
looks good, thanks.
>
> Subject: [PATCH] oom: show vsz and rss informati
Dave Korn wrote:
Andrew Morton wrote:
On Mon, 2 Nov 2009 13:29:29 -0800 Justin Mattock
wrote:
Hello,
I'm not sure how to handle this,
while compiling firefox-3.6b1.source
I get this with the default compiling options,
as well as custom:
...
active_anon:2360492kB inactive_anon:590
On Tue, Nov 3, 2009 at 9:09 PM, Roland McGrath wrote:
> I can't really tell how that's different from the patch I posted.
> It looks fine to me.
>
The difference is you can set the default linker.
--
H.J.
I the GO_IF_LEGITIMATE_ADDRESS address macro i am allowing this
address because the target supports symbolic address in QImode for
store operations.
If your target can not use a symbolic address in a QImode load, then
GO_IF_LEGITIMATE_ADDRESS must reject symbolic addresses in QImode. It's
Mohamed Shafi wrote:
> Load-store uses 32bits. Sign extension happens automatically. So i
> have choosen INT_MODE (RI, 5) and copied movsi and renamed it to
> movri. I have also specified that RImode need only one register.
> I get the following ICE
>
> internal compiler error: in immed_double_c
2009/10/30 Ian Lance Taylor :
> Mohamed Shafi writes:
>
>>>From ice4.c.168r.asmcons
>>
>> (insn 5 2 6 2 ice4.c:4 (set (reg:SI 61 [ s ])
>> (mem/c/i:SI (symbol_ref:SI ("s") [flags 0x2] > 0xb7bfd000 s>) [0 s+0 S4 A32])) 2 {*movsi_internal} (nil))
>>
>> (insn 6 5 7 2 ice4.c:4 (set (reg:QI 62)
2009/10/30 Jeff Law :
> On 10/30/09 07:13, Mohamed Shafi wrote:
>>
>> Hi,
>>
>> I am doing a port for a 32bit target in GCC 4.4.0. The target does not
>> have support for symbolic address in QImode for load operations.
>
> You'll need to make sure to reject such addresses for QImode in
> GO_IF_LEGI
2009/10/22 Richard Henderson :
> On 10/21/2009 07:25 AM, Mohamed Shafi wrote:
>>
>> For accessing a->b GCC generates the following code:
>>
>> move.l (sp-16), d3
>> lsrr.l #<16, d3
>> move.l (sp-12),d2
>> asll #<16,d2
>> or d3,d2
>> cmpeq.w #<2,d
Andrew Morton wrote:
> On Mon, 2 Nov 2009 13:29:29 -0800 Justin Mattock
> wrote:
>
>> Hello,
>> I'm not sure how to handle this,
>> while compiling firefox-3.6b1.source
>> I get this with the default compiling options,
>> as well as custom:
>>
>> ...
>>
>> active_anon:2360492kB inactive_anon:590
> On Mon, 2 Nov 2009 13:29:29 -0800 Justin Mattock
> wrote:
>
> > Hello,
> > I'm not sure how to handle this,
> > while compiling firefox-3.6b1.source
> > I get this with the default compiling options,
> > as well as custom:
> >
> > ...
> >
> > active_anon:2360492kB inactive_anon:590196kB activ
On 11/04/2009 07:44 AM, Justin P. Mattock wrote:
> as for compiling: libc compiled fine, kernel fine,
> and every package on the clfs list up to boot up the fresh system.
It might be pretty c++ only, I think.
35 matches
Mail list logo
