search for: significantely

Hi, I've noticed that the funcionality in the Verifier.cpp significantely slows down the compilation, especially for big basic blocks. In this case the llvm::DominatorTree::dominates() seems to consume a lot of time. Some debugging has shown that it is the Assert2() macro usage in the Verifier::visitInstruction(), arount this place: // Definition must dominate use...

...for this purpose Actually, PhysRegsUseOrder isn't really needed for BigBlock - it's a leftover from the local allocator. So there are even more brutal performance fixes to be made to BigBlock, however your suggestion applies to the Local allocator for sure! > I think these changes may significantely improve the performance of > your BigBlock register allocator. I'll try to come up with some more > concrete proposals or even patches over the week-end or next week. Patches would be a dream - while I don't expect BigBlock to ever be more than ~25% of total codegen time, every littl...

...sRegsUseOrder - you remove some elements from the middle of this vector in removePhysReg. This is not a very efficient operation on the vectors, since it need to copy the tail of the vector. I think using a list data-structure could be much more efficient for this purpose I think these changes may significantely improve the performance of your BigBlock register allocator. I'll try to come up with some more concrete proposals or even patches over the week-end or next week. -Roman __________________________________________________ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herau...

...e, double-click. You: launch libguestfs > instance, call list-filesystems and display them. > Right, adding another level of file-systems is possible. The downside though is that I then stop seeing the directory-structure from the guest point of view, right? Maybe it's not that bad if it significantely improves the responsiveness... > 2. User: selects some file system, double-click. You: mount file > system, call ll (or friends) and display top-level file system > hierarchy. > 3. User: selects directory, double-click. You: call ll (or friends) to > discover and display next level...

...o a new TF node TFi. Then all such TFs are put into a big parent TF, that has only these TFi nodes as operands: _____TF______ / \ TF1 ... __TFk__ / \ / \ LD1.1..LD1.64 LDk.1...LDk.64 These changes (a) and (b) significantely reduce the compilation time on my pathological use-cases with huge TokenFactors. I attach the proposed patch to this mail for review. The only questions I still have are the following: - Which approach is better, b.1 or b.2? - If I have a huge number k of loads/nodes (i.e. nodes N1 ... Nk), to...

...d guestfs might not be found all mappings. Even more: you will not get mappings if guetsfs unable to detect OS or there are no OS at all on the disk(s) you are browsing. And side question: are you ready to the situation where inspect-os find more then one OS? > Maybe it's not that bad if it significantely improves the responsiveness... Anyway you need to prepared to display disk(s)/VM from guest(s) point of view as well as simply browsing found file systems. > But on the other hand, I do want to enable the user to browse a single disk image even if it was attached to the VM along with few other...

Hi everyone, Quick summary: LLVM now has a new register allocator particularly suitable for compiling (very) large, machine-generated functions. Longer story: I've recently been using LLVM in an application that involves JITing fairly large functions that have no control flow - they're just flat sequences of instructions, anywhere from 100 to 10000+ in size. (The control flow is

...ese TFi nodes as > > operands: > > _____TF______ > > / \ > > TF1 ... __TFk__ > > / \ / \ > > LD1.1..LD1.64 LDk.1...LDk.64 > > > > > > These changes (a) and (b) significantely reduce the compilation time > > on my pathological use-cases with huge TokenFactors. > > > > I attach the proposed patch to this mail for review. > > > > The only questions I still have are the following: > > - Which approach is better, b.1 or b.2? > > I...

Hi All, In the last few days, I've been working on leveraging a pluggable mechanism that is going to be introduced for muCommander [1] to provide a front-end for libguestfs. I published a video [2] that demonstrates this integration: enabling to browse/upload-to/download-from virtual disks via a file manager with a dual-pane interface. I've followed the guidelines for inspecting the