search for: alloctions

Hi all, Sorry to bother those not interested in this problem. I have a problem while I want to reuse the liveness information after register allocation. When I use the livein_begin() from MachineBasicBlock to get the live-in registers after register alloction. I found that the liveness information is sometime incorrect. For example, some registers should be live-in to the machine basic block as

Hi, I have ported LLC to a risc cpu. It can pass benchmark that I have at current. But I want do some optimization after register alloction by adjusting register using. I scan MachineBasicBlock to analyze operand's IsKill, IsDead , IsDef attribute to get a physical register's liverange. But I get a strange case at MBB.jpg. R4 is marked <kill> at MBB0. If I scan R4's

Am 27.09.18 um 10:04 schrieb Rowland Penny via samba: > On Thu, 27 Sep 2018 07:46:40 +0200 > Daniel Jordan <d.jordan at gfd.de> wrote: > > >> Hello  Andrew and Rowland, >> >> here's the ldbsearch output from both domain controllers: >> >> >> dc01:~# ldbsearch -H /var/lib/samba/private/sam.ldb >> '(&(objectClass=rIDSet)(cn=RID

We have our user set up with quotas on RedHat Linux server(5.1). It works under the normal linux enviroment. BUT when we use SAMBA to get the user's home directory mapped to drive letter on a WINNTmachine (4 with SP 3) it doesn't maintain the quota. After using all the allocted space user can still copy files to that drive which is mapped for user's home directory. Does anybody else

On Jan 14, 2010, at 6:39 PM, 任坤 wrote: > But I want do some optimization after register alloction by adjusting > register using. I scan MachineBasicBlock to analyze operand's IsKill, IsDead , IsDef attribute to get a physical register's liverange. But I get a strange case at MBB.jpg. You can also look at RegisterScavenging.cpp and MachineVerifier.cpp. They are doing the same

Hello, I'm getting the "LLVM ERROR: ran out of registers during register allocation" error message for an out of tree target I'm developing. This is happening for the following piece of C code: struct ss { int a; int b; int c; }; void loop(struct ss *x, struct ss **y, int z) { int i; for (i=0; i<z; ++i) { x->c += y[i]->b; } } The problem relies in

I had a small peak at your patch. This also applies to samba 4.8.5? Now, basicly, i dont know anythis what that patch is doing, im not a coder, i can read it a bit. But if did read it correct, its about rID pool alloctions where rID = 0 ? Like this: (dn: CN=RID Set,CN=DC2,OU=Domain Controllers,) rIDAllocationPool: 2100-2599 rIDPreviousAllocationPool: 0-0 rIDUsedPool: 0 rIDNextRID: 0 And on DC1 i see : rIDAllocationPool: 2600-3099 rIDPreviousAllocationPool: 2600-3099 rIDUsedPool: 1 whenChanged: 20161220102428.0Z u...

Hi,All I setup traffic control configuration with HTB this way: 1: root HTB qdisc | 1:1 HTB class rate 1024kbit | /-----+-----+-----+------+-----\ 1:10 1:20 1:30 1:40 1:50 1:60 EF AF41 AF31 AF21 AF11 BE and alloct different bandwidth to these PHBs(queues).So which tool would I use to generate these packets at the same to for

On Dec 17, 2012, at 8:38 AM, Borja Ferrer <borja.ferav at gmail.com> wrote: > Hello, > > I'm getting the "LLVM ERROR: ran out of registers during register allocation" error message for an out of tree target I'm developing. This is happening for the following piece of C code: > > struct ss > { > int a; > int b; > int c; > }; > void

Hi, I'm now ready to implement the FP support for my embedded target. My target supports only f64 at the moment. Question: How can I tell LLVM that float is the same as double on my target? May be by assigning the same register class to both MVT::f32 and MVT::f64? But FP is supported only in the emulated mode, because the target does not have any hardware support for FP. Therefore each FP

Dave Airlie <airlied at gmail.com> writes: > Hi Rusty, > > current virtio-ring.c has a BUG_ON in virtqueue_add that checks > total_sg > vg->vring.num, however I'm not sure it really is 100% > correct. > > If I have an indirect ring and I'm adding sgs to it and the host is > delayed (say I've got a thread consuming things from the vring and its >

Dave Airlie <airlied at gmail.com> writes: > Hi Rusty, > > current virtio-ring.c has a BUG_ON in virtqueue_add that checks > total_sg > vg->vring.num, however I'm not sure it really is 100% > correct. > > If I have an indirect ring and I'm adding sgs to it and the host is > delayed (say I've got a thread consuming things from the vring and its >

Hi, I'm hitting this bug with both ext4 and btrfs. Here's an example of the backtrace: https://gist.github.com/vzctl/e888a821333979120932 I tried raising this BUG only for direct ring and it solved the problem: - BUG_ON(total_sg > vq->vring.num); + BUG_ON(total_sg > vq->vring.num && !vq->indirect); Shall I submit the patch or is a more elaborate fix

Hi, I'm hitting this bug with both ext4 and btrfs. Here's an example of the backtrace: https://gist.github.com/vzctl/e888a821333979120932 I tried raising this BUG only for direct ring and it solved the problem: - BUG_ON(total_sg > vq->vring.num); + BUG_ON(total_sg > vq->vring.num && !vq->indirect); Shall I submit the patch or is a more elaborate fix

Hi Chris, Thanks for this info. This provides even better and more advanced examples of multiclass usage! But your previous explanations were so good that I implemented in my backend last week almost the same that you've done now in the X86InstrSSE.td. I even introduced isCommutable parameter to indicate this property, just as you did. So, by now integer arithmetic and general purpose

For anyone interested, X86InstrSSE.td makes extensive use of multiclasses now if people are looking for examples other than the sparc backend. -Chris -- http://nondot.org/sabre/ http://llvm.org/

On Mon, 9 Oct 2006, Roman Levenstein wrote: > I'm now ready to implement the FP support for my embedded target. cool. > My target supports only f64 at the moment. > Question: How can I tell LLVM that float is the same as double on my > target? May be by assigning the same register class to both MVT::f32 > and MVT::f64? Just don't assign a register class for the f32 type.

The Rprofmem facility is currently enabled only if the configuration option --enable-memory-profiling is used. However, the overhead of having it enabled is negligible when profiling is not actually being done, and can easily be made even smaller. So I think it ought to be enabled all the time. I've attached a patch doing this, which also makes a number of other improvements to Rprofmem,