search for: ahas

Hi Daniel! Daniel Dunbar wrote: > I merged in my changes to your patch, which results in the attached > patch. There may be some missed merge errors. The main problem I have > with the rest of this patch is that it causes a regression in > llvm-prof's behavior. I tried running edge profiling on the > MultiSource/Applications/aha benchmark in the llvm test-suite, and >

Hi Andreas, Sorry for the lag time... On Wed, Jul 22, 2009 at 5:47 AM, Andreas Neustifter<e0325716 at student.tuwien.ac.at> wrote: > Hi Daniel! > > Daniel Dunbar wrote: >> I merged in my changes to your patch, which results in the attached >> patch. There may be some missed merge errors. The main problem I have >> with the rest of this patch is that it causes a

Good Morning. On 22.07.09 14:47), Andreas Neustifter wrote: > Daniel Dunbar wrote: >> I merged in my changes to your patch, which results in the attached >> patch. There may be some missed merge errors. The main problem I have >> with the rest of this patch is that it causes a regression in >> llvm-prof's behavior. I tried running edge profiling on the >>

Sorry, forgot attachment. On 23.07.09 07:40), Andreas Neustifter wrote: > Good Morning. > > On 22.07.09 14:47), Andreas Neustifter wrote: >> Daniel Dunbar wrote: >>> I merged in my changes to your patch, which results in the attached >>> patch. There may be some missed merge errors. The main problem I have >>> with the rest of this patch is that it

Hi! Daniel Dunbar wrote: > > Sorry for the lag time... No problem. As long as I know that you get to it sometime its fine for me... > On Wed, Jul 22, 2009 at 5:47 AM, Andreas > Neustifter<e0325716 at student.tuwien.ac.at> wrote: >> Hi Daniel! >> >> Daniel Dunbar wrote: >>> I merged in my changes to your patch, which results in the attached

Hi Andreas, Thanks for breaking things up. I applied two pieces of this patch in separate no-functionality-change commits, here: http://llvm.org/viewvc/llvm-project?view=rev&revision=75623 and here: http://llvm.org/viewvc/llvm-project?view=rev&revision=75625 I merged in my changes to your patch, which results in the attached patch. There may be some missed merge errors. The main

Hi, this is the first in a series of patches to cleanup and improve the LLVM Profiling Infrastructure. First and foremost this patch removes duplicate functionality from ProfileInfoLoader and ProfileInfo: The ProfileInfoLoader performed not only the loading of the profile information but also some synthesis of block and function execution counts from edge profiling information. Since the

On Wed, Aug 5, 2009 at 12:22 PM, Andreas Neustifter<e0325716 at student.tuwien.ac.at> wrote: >> On Wed, Jul 22, 2009 at 5:47 AM, Andreas >> Neustifter<e0325716 at student.tuwien.ac.at> wrote: >>> >>> Hi Daniel! >>> >>> Daniel Dunbar wrote: >>>> >>>> I merged in my changes to your patch, which results in the

I have patches to add locking to the adv(4), adw(4), aha(4), ahb(4), aic(4), and bt(4) drivers so that they no longer use Giant. I would appreciate any testing folks are able to do. The patches are against HEAD but should apply to 8 or 9. Make sure you have INVARIANTS and INVARIANT_SUPPORT enabled for any initial testing that you do. Thanks!

I am running CentOS 4.7, presently on an older box (PIII slot 1 processor @ 500mhz with 384meg of RAM, using SCSI disks with an AHA-2940 host controller). I have built a new box: AMH Semporon 2.<mumble> GHZ, 2gig of RAM. I put in a AHA-29160 host controller (uses same driver as the AHA-2940). The motherboard is an ASROCK thing with nVideo's chipset: nv's SATA controller and

...(1) kill -USR2 `cat unicorn.pid` (via Capistrano deployment task for example) (2) Inside the "before_exec" hook in the config file, do: kill -QUIT `cat unicorn.pid.oldbin` My question is: By the time the "before_exec" hook is executed, is it guaranteed that unicorn.pid.oldbin ahas lready created (otherwise we have a racing condition here)? Or is there a better way to achieve what I want? Please Cc me as I am not on the mailing list. Please also let me know if there is a better place to ask this question. Thanks, Pai-Hung

Hi Bob, are these performance regressions real? They look pretty serious. Ciao, Duncan. On 10/12/11 09:40, llvm-testresults at cs.uiuc.edu wrote: > > bwilson__llvm-gcc_PROD__i386 nightly tester results > > URL http://llvm.org/perf/db_default/simple/nts/332/ > Nickname bwilson__llvm-gcc_PROD__i386:4 > Name curlew.apple.com > > Run ID Order Start Time End Time >

it seems that when you say "check for new mail" in apple mail, it sends a NOOP to the imap server to get the response. in uw, the conversation is something like: 25 NOOP 25 OK NOOP completed 26 NOOP * 2796 EXISTS * 7 RECENT 26 OK NOOP completed however, with dovecot, if it has already notified the client that new mail has arrived, it will look something like: * 24 EXISTS * 2 RECENT

Consider the following method: def name_to_terminal puts "Scott Taylor" end How would I spec this out? Scott

> The issue here is more arbitrary differences due to different default > code generation choices; for example, clang defaults to generating > SSE2 code, while llvm-gcc defaults to using x87 FP. Aha, this explains some apparently bizarre results such as the second one (018427, d) on this page: http://embed.cs.utah.edu/embarrassing/dec_09/harvest/llvm-gcc-head_clang-head/ I had been

On 22/09/10 18:07, Jim Grosbach wrote: [...] > Are you running 'opt' on your bitcode or otherwise manually running those passes? Aha. After running opt I now have inlined (and much better) code. Previously I'd been using llc -O3 to do the optimisation. What's the different between opt -O3 and llc -O3, then? -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ───── │ "To

Hello, does CentOs 5 supports an Adaptec AHA-2940W/2940UW scsi controller (pci)? Is this controller maybe supported by the aic7xxx driver? I want to install CentOS 5 on my desktop pc but the currently installed pci scsi controller for my scanners (drivers: 2x tmscsim, 1x advansys) are not supported by CentOS. So I am searching for something else. Thanks in advanced. regards Olaf

On Thursday 11 October 2007 11:24, David Greene wrote: > Somehow PointerType::get is returning a 64-bit pointer even though > -m32 was passed to llvm-gcc. > > I'll see if I can figure out where the 64-bit code warning is emitted and > what triggers it. Aha! I found this previous thread: http://lists.cs.uiuc.edu/pipermail/llvmdev/2007-May/009177.html I am now trying to build

Yes, they are real. I re-ran the two tests with the biggest execution time regressions, and the results were completely reproducible. On Oct 12, 2011, at 1:24 AM, Duncan Sands wrote: > Hi Bob, are these performance regressions real? They look pretty serious. > > Ciao, Duncan. > > On 10/12/11 09:40, llvm-testresults at cs.uiuc.edu wrote: >> >>

On Wed, Dec 2, 2015 at 1:36 PM, Samuel Thibault <samuel.thibault at ens-lyon.org> wrote: > Hello, > > Dave Taht, on Wed 02 Dec 2015 13:21:56 +0100, wrote: >> I'd made a start on the send direction here: >> https://github.com/dtaht/tinc/commits/master >> >> Perhaps that will help. > > Well, converting a sendto call into a sendmsg call is not really