search for: buchwald

Hi, This is the first time I have tried to expand the storage of a live gluster volume. I was able to get another supermicro storage unit for a gluster cluster that I built. The current clustered storage configuration contains five supermicro units. And the cluster volume is setup with the following configuration: node-6[/var/log/glusterfs]# gluster volume info Volume Name: researchdata

...Sebastian suggested (i.e. considering the cost of adjacent nodes). This made the allocation better, but allocation time went very high --- but I had no time to try to improve the heuristic. I did not know about Sebastian et al paper, so thanks for pointing to it ! Cheers, Arnaud From: Sebastian Buchwald [mailto:Sebastian.Buchwald at kit.edu] Sent: 02 June 2016 20:57 To: llvm-dev at lists.llvm.org; james at jamesmolloy.co.uk; lhames at gmail.com; Arnaud De Grandmaison Subject: Re: [llvm-dev] PBQP register allocation and copy propagation On 06/02/2016 07:22 PM, James Molloy via llvm-dev wrote: Hi L...

...g defs that cause the reduction rule to change to RN: %vregC = def... %vregD = def... %vregB = COPY %R0 %vregA = COPY %vregB = use %vregC, %vregD Now the reduction order is arbitrary and local costs aren't propagated unlike R1 and R2. In fact, there is a rule "RM" proposed by Buchwald [1] that seeks to fix a very similar case to this. What do you think? Cheers, James [1] SSA-based Register Allocation with PBQP, Buchwald et al, https://pp.info.uni-karlsruhe.de/uploads/publikationen/buchwald11cc.pdf -------------- next part -------------- An HTML attachment was scrubbed... URL...

...I >> had no time to try to improve the heuristic. >> >> >> >> I did not know about Sebastian et al paper, so thanks for pointing to it >> ! >> >> >> >> Cheers, >> >> Arnaud >> >> >> >> *From:* Sebastian Buchwald [mailto:Sebastian.Buchwald at kit.edu] >> *Sent:* 02 June 2016 20:57 >> *To:* llvm-dev at lists.llvm.org; james at jamesmolloy.co.uk; lhames at gmail.com; >> Arnaud De Grandmaison >> *Subject:* Re: [llvm-dev] PBQP register allocation and copy propagation >> >> &g...

> (1) Spill cost metrics. I think this one cannot be dissociated from some kind of live range pre-splitting. Cheers, Arnaud From: Lang Hames [mailto:lhames at gmail.com] Sent: 03 June 2016 23:15 To: James Molloy Cc: Arnaud De Grandmaison; llvm-dev at lists.llvm.org; Sebastian Buchwald; Bernhard Scholz Subject: Re: [llvm-dev] PBQP register allocation and copy propagation Hi James, Arnaud, Sebastian, I think one idea to improve the situation is to consider the cost vector of adjacent nodes during RN. Let's say you decided to do a RN for node A and want to compute the costs f...

Hi, On 14.03.2024 01:39, Theodore Buchwald wrote: > > ... So my question is. What would be the correct amount of bricks > needed to expand the storage on the current configuration of 'Number > of Bricks: 1 x (4 + 1) = 5'? ... > I tried something similar and ended up with a similar error. As far as I understand the do...

...dding these 3 papers to your reading list. Register allocation for programs in SSA-form Sebastian Hack, Daniel Grund, and Gerhard Goos http://www.rw.cdl.uni-saarland.de/~grund/papers/cc06-ra_ssa.pdf Simple and Efficient Construction of Static Single Assignment Form Matthias Braun , Sebastian Buchwald , Sebastian Hack , Roland Leißa , Christoph Mallon , and Andreas Zwinkau https://www.info.uni-karlsruhe.de/uploads/publikationen/braun13cc.pdf Optimal register allocation for SSA-form programs in polynomial time Sebastian Hack, Gerhard Goos http://web.cs.ucla.edu/~palsberg/course/cs232/papers/...

Lang Hames wrote: > Hi Sebastian, > > > We did. The success of normalization in this case depends on whether > you attempt to normalize rows first, then columns, or the other way > around. > > Currently rows are normalized first, then columns. In your example the > infinite costs are thus propagated onto element 1 of node 0, rather > than node 4, which leaves us

On Sun, 2010-01-31 at 13:28 +1100, Lang Hames wrote: > Hi Sebastian, > > It boils down to this: The previous heuristic solver could return > infinite cost solutions in some rare cases (despite finite-cost > solutions existing). The new solver is still heuristic, but it should > always return a finite cost solution if one exists. It does this by > avoiding early reduction of

Hi Lang, I'm surprised about the fact that you omit R1/R2 reductions in some cases. Can you give a more detailed description of the bug (e.g. a PBQP dump)? Best regards, Sebastian Lang Hames wrote: > Hi Sachin, llvm-dev, > > I've just committed a new PBQP solver which, among other things, > should take care of this bug. > > Please let me know how it works out for you.