Nicolas Pitre <[EMAIL PROTECTED]> writes:
> Well... This is weird.
>
> It seems that memory fragmentation is really really killing us here.
> The fact that the Google allocator did manage to waste quite less memory
> is a good indicator already.
Maybe an malloc/free/mmap wrapper that records t
Hello,
I think you should add the pair of constraints m and I respectively to
the description of the instruction in your md file (and a relevant
case 8 to handle such instruction), i.e.:
(define_insn "movqi"
- [(set (match_operand:QI 0 "nonimmediate_operand" "=p,q,m,m,p,q,p,q")
-(match_
Hi Revital1,
Thank you very much for your help. The ISA I am using
(OpenRISC) does not provide an alternative for moving a constant into
memory. The only way of doing this is to move the constant into a
register (which i am doing) and then move that register value into
memory. So what can
On 12 December 2007 12:14, Revital1 Eres wrote:
> It seems that the pair m and I is missing (which indicate the memory =
> constant instruction).
So doesn't the question then become "Why isn't reload reloading the constant
into a register"?
cheers,
DaveK
--
Can't think of a witty
On Wed, Dec 12, 2007 at 12:06:04AM -0500, Balaji V. Iyer wrote:
> Hello Everyone,
> I got past that negdi2 and some errors..now I am trying to compile
> some linux module, and it says I am not able to find this constraint:
>
> init/main.c: In function 'start_kernel':
> init/main.c:441: error:
> I "implemented" branch delay slots (define_delay) for my
> architecture and I use the command line option -fdelayed-branch. But
> branch delay slot filling is done just for a few candidates. Even for
> the same rule within the same compilation unit (C file) it is done in
> a few cases but not i
Boris Boesler <[EMAIL PROTECTED]> writes:
> I "implemented" branch delay slots (define_delay) for my
> architecture and I use the command line option -fdelayed-branch. But
> branch delay slot filling is done just for a few candidates. Even for
> the same rule within the same compilation unit (C
On Wed, 12 Dec 2007, Nicolas Pitre wrote:
> Add memory fragmentation to that and you have a clogged system.
>
> Solution:
>
> pack.deltacachesize=1
> pack.windowmemory=16M
>
> Limiting the window memory to 16MB will automatically shrink the window
> size when big objects are encou
When I returned to the computer this morning, the repack was
completed... with a 1.3GB pack instead.
So... The gcc repo apparently really needs a large window to efficiently
compress those large objects.
So, am I right that if you have a very well-done pack (such as gcc's),
you might want
On Wed, 12 Dec 2007, Nicolas Pitre wrote:
> I did modify the progress display to show accounted memory that was
> allocated vs memory that was freed but still not released to the system.
> At least that gives you an idea of memory allocation and fragmentation
> with glibc in real time:
>
> di
On Wed, 12 Dec 2007, Nicolas Pitre wrote:
>
> So... my conclusion is that the glibc allocator has fragmentation issues
> with this work load, given the notable difference with the Google
> allocator, which itself might not be completely immune to fragmentation
> issues of its own.
Yes.
Not
On Wed, 12 Dec 2007, David Miller wrote:
>
> I personally don't think it's unreasonable for GIT to have it's
> own customized allocator at least for certain object types.
Well, we actually already *do* have a customized allocator, but currently
only for the actual core "object descriptor" that
From: Linus Torvalds <[EMAIL PROTECTED]>
Date: Wed, 12 Dec 2007 08:37:10 -0800 (PST)
> I'm not saying that particular case happens in git, I'm just saying that
> it's not unheard of. And with the delta cache and the object lookup, it's
> not at _all_ impossible that we hit the "allocate in one t
On Wed, Dec 12, 2007 at 01:01:00PM -, Dave Korn wrote:
> On 12 December 2007 12:14, Revital1 Eres wrote:
>
> > It seems that the pair m and I is missing (which indicate the memory =
> > constant instruction).
>
> So doesn't the question then become "Why isn't reload reloading the constant
On 12/12/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>
> On Wed, 12 Dec 2007, Nicolas Pitre wrote:
> >
> > So... my conclusion is that the glibc allocator has fragmentation issues
> > with this work load, given the notable difference with the Google
> > allocator, which itself might not be comp
Am 12.12.2007 um 16:21 schrieb Ian Lance Taylor:
Boris Boesler <[EMAIL PROTECTED]> writes:
I "implemented" branch delay slots (define_delay) for my
architecture and I use the command line option -fdelayed-branch. But
branch delay slot filling is done just for a few candidates. Even for
the s
Boris Boesler <[EMAIL PROTECTED]> writes:
> Ok, I think I found it: GCC leaves control-flow operations as they
> are, if it can not place other operations in branch delay slots
> (represented as SEQUENCEs in GCC); or in other words: GCC does not
> represent empty delay slots.
>
> Is this
At http://gcc.gnu.org/ml/gcc/2007-12/msg00360.html, Andreas Ericsson
<[EMAIL PROTECTED]> wrote:
> If it's still an issue next week, we'll have a 16 core (8 dual-core cpu's)
> machine with some 32gb of ram in that'll be free for about two days.
> You'll have to remind me about it though, as I've got
Hi,
On Wed, 12 Dec 2007, J.C. Pizarro wrote:
> It's good idea if it's for 24/365.25 that it does
> autorepack-compute-again-again-again-those-unexplored-deltas of
> git repositories in realtime. :D
This sentence does not parse.
> Some body can do "git clone" that it could give smaller that on
Over the last few weeks we (Google) have been discussing ideas on how to
leverage the LTO work to implement a whole program optimizer that is
both fast and scalable.
While we do not have everything thought out in detail, we think we have
enough to start doing some implementation work. I tried a
On 2007/12/12, "Diego Novillo" <[EMAIL PROTECTED]> wrote:
> Over the last few weeks we (Google) have been discussing ideas on how to
> leverage the LTO work to implement a whole program optimizer that is
> both fast and scalable.
>
> While we do not have everything thought out in detail, we think w
On 12/12/2007, J.C. Pizarro <[EMAIL PROTECTED]> wrote:
>
> * The googlish user says
> "i'm using the massive googlecc compiler that uses a lot of tons
> of libraries
> distributed in all the world!"
>
> * google shutdown => googlecc compiler doesn't work, ended history, byebye.
Yet agai
On 2007/12/12, Jonathan Wakely <[EMAIL PROTECTED]> wrote:
> On 12/12/2007, J.C. Pizarro <[EMAIL PROTECTED]> wrote:
> >
> > * The googlish user says
> > "i'm using the massive googlecc compiler that uses a lot of tons
> > of libraries
> > distributed in all the world!"
> >
> > * google sh
Snapshot gcc-4.2-20071212 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20071212/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.2 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On Wed, Dec 12, 2007 at 11:42:23PM +0100, J.C. Pizarro wrote:
> They are gaming or playing with the words of the language for Google.
This is absurd and off-topic. Please stop.
--
Daniel Jacobowitz
CodeSourcery
Please stop spamming my gcc@gcc.gnu.org email box.
All the messages that you sent are just off-topic for this mailing list.
Please STOP sending emails.
Thank you,
Sebastian Pop
On Dec 12, 2007 4:42 PM, J.C. Pizarro <[EMAIL PROTECTED]> wrote:
>
> On 2007/12/12, Jonathan Wakely <[EMAIL PROTECTED]>
On Wed, 2007-12-12 at 15:06 -0500, Diego Novillo wrote:
> Over the last few weeks we (Google) have been discussing ideas on how to
> leverage the LTO work to implement a whole program optimizer that is
> both fast and scalable.
>
> While we do not have everything thought out in detail, we think we
On Wed, 2007-12-12 at 15:06 -0500, Diego Novillo wrote:
> Over the last few weeks we (Google) have been discussing ideas on how to
> leverage the LTO work to implement a whole program optimizer that is
> both fast and scalable.
>
> While we do not have everything thought out in detail, we think we
On 12/12/2007, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:
> On Wed, Dec 12, 2007 at 11:42:23PM +0100, J.C. Pizarro wrote:
> > They are gaming or playing with the words of the language for Google.
>
> This is absurd and off-topic. Please stop.
>
This time it went too far. We have been infinitely
On Dec 12, 2007, at 3:41 PM, Harvey Harrison wrote:
In terms of implementation, we will likely use the LTO branch as a
basis. Many of the features we will need are already being
implemented
in the branch, so we will keep helping with that implementation.
I'm curious how this interacts/compl
On Wed, 2007-12-12 at 16:02 -0800, Chris Lattner wrote:
> On Dec 12, 2007, at 3:41 PM, Harvey Harrison wrote:
> >> In terms of implementation, we will likely use the LTO branch as a
> >> basis. Many of the features we will need are already being
> >> implemented
> >> in the branch, so we will kee
> While we do not have everything thought out in detail, we think we have
> enough to start doing some implementation work. I tried attaching the
> document, but the mailing list rejected it. I've uploaded it to
> http://airs.com/dnovillo/pub/whopr.pdf
>
Very very interesting proposal indeed!
I
Nicolas Pitre wrote:
On Wed, 12 Dec 2007, Nicolas Pitre wrote:
I did modify the progress display to show accounted memory that was
allocated vs memory that was freed but still not released to the system.
At least that gives you an idea of memory allocation and fragmentation
with glibc in rea
On Dec 12, 2007 3:28 PM, Tim Josling <[EMAIL PROTECTED]> wrote:
>
> Do you have any thoughts on how this approach would be able to use
> profiling information, which is very a very powerful source of
> information for producing good optimisations?
The intent is for the WPA phase to utilize profile
On Dec 12, 2007 11:14 PM, Praveen Raghavan <[EMAIL PROTECTED]> wrote:
>
> 1. Are there also plans to extend the global transformation
> capabilities. I see that the original set of global transformations is
> limited (rightfully so).
This is still at a very early design stage. Additional
transfor
35 matches
Mail list logo
