similar to: [LLVMdev] What's up with the buildbots?

On Sep 24, 2010, at 7:13 PM, Jakob Stoklund Olesen wrote: > It looks like they are not starting new builds automatically any more. Blame lists on forced builds are empty. It seems the master has gone blind to svn updates. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1929 bytes Desc: not available URL:

On Jan 7, 2011, at 11:25 AM, Dale Johannesen wrote: > We might want to make physical registers negative and virtuals positive, or vice versa. Then FirstVirtualRegister is 0 or 1, and we could get rid of those annoying subtractions of FirstVirtualRegister all over the virtual-register-handling passes. Since 0 is used all over the place as "invalid register" it is probably best to

Thanks for giving it a look! On 19.10.2010 23:21, Jakob Stoklund Olesen wrote: > On Oct 19, 2010, at 11:40 AM, Roland Scheidegger wrote: > >> So I saw that the code is doing lots of register >> spilling/reloading. Now I understand that due to calling >> conventions, there's not really a way to avoid this - I tried using >> coldcc but apparently the backend

On Oct 19, 2010, at 6:37 PM, Roland Scheidegger wrote: > Thanks for giving it a look! > > On 19.10.2010 23:21, Jakob Stoklund Olesen wrote: >> On Oct 19, 2010, at 11:40 AM, Roland Scheidegger wrote: >> >>> So I saw that the code is doing lots of register >>> spilling/reloading. Now I understand that due to calling >>> conventions, there's not

I noticed that we generate code like this for i386 PIC: calll L0$pb L0$pb: popl %eax movl %eax, -24(%ebp) ## 4-byte Spill I worry that this defeats the return address prediction for returns in the function because calls and returns no longer are matched. From Intel's Optimization Reference Manual: "The return address stack mechanism augments the static and dynamic

Hi Jakob, Here is the first draft of the patch to add TableGen backend support for the instruction mapping tables. Please take a look and let me know your suggestions. As of now, I create one mapping table per relation which results into a long .inc file. So, I'm planning to combine everything into a single table and will include APIs (one per relation) to query from this table. Thanks,

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

Jakob Stoklund Olesen <stoklund at 2pi.dk> writes: > On Sep 19, 2012, at 10:49 AM, <dag at cray.com> wrote: > >> Jakob Stoklund Olesen <stoklund at 2pi.dk> writes: >> >> So if there are multiple values between r2 and r3 (r2.1, r2.2, etc.) I >> would just follow the chains implied by the SibValueInfo Deps array? >> Basically, I want to find

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

Hi Jakob, Did you get a chance to look at the patch? Thanks, Jyotsna -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Jyotsna Verma Sent: Tuesday, August 28, 2012 1:01 PM To: 'Jakob Stoklund Olesen' Cc: llvmdev at

On May 17, 2010, at 6:21 PM, Chris Lattner wrote: > > On May 17, 2010, at 5:43 PM, Jakob Stoklund Olesen wrote: > >> As you may have noticed, I have been working on a fast register allocator in the last week. The new allocator is intended to replace the local allocator for debug builds. > > This is great work Jakob! What is required and when do you think you'll be

Jakob Stoklund Olesen <stoklund at 2pi.dk> writes: >> If we decide to spill r3, we call traceSiblingValue to find the original >> def (the load). After traceSiblingValue we have the load instruction to >> define r1 and the value number information for r3. We don't have the >> value information from r2 as far as I can tell. >> >> Is that correct?

On Aug 6, 2012, at 11:16 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > > The getNextOperandForReg() function isn't used anywhere, Should we remove it? -Jim

Jakob Stoklund Olesen <stoklund at 2pi.dk> writes: > On Nov 16, 2011, at 9:15 AM, David Greene wrote: > >> I'm working on some enhancements to rematerialization that I hope to >> contribute. > > What do you have in mind? Rematting more types of loads. >> /// getReMatImplicitUse - If the remat definition MI has one (for now, we only >> /// allow one)

On Thu, Aug 2, 2012 at 5:23 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > The problem is, this isn't really any better than having a large switch statement. You just moved the table into the .td file. > > You should be taking advantage of the instruction multiclasses so you don't have to maintain a full table of opcodes. We wouldn't need to

Based on discussions with Lang Hames and Jakob Stoklund Olesen at the hacker's lab, and in the light of upcoming work on the PBQP register allocator, it was though that CalcSpillWeights does not need to be a pass. This change will enable to customize / tune the spill weight computation depending on the allocator. Update the documentation style while there. I also intend to take

On Oct 11, 2011, at 1:33 PM, David A. Greene wrote: > Jakob Stoklund Olesen <stoklund at 2pi.dk> writes: > >> How about: > > foreach x = [...] > > I could do > > foreach x in [...] > > but that requires another keyword. Do we care? The syntax should be consistent with let expressions, even if the meaning is completely different. That is:

Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote on 24.04.2013 23:47:54: > I would like to add one more case here: Fixed register operands. > > Some instructions, like x86's MUL and DIV, take operands in fixed > registers. Currently, we handle that with COPY instructions to and > from the fixed registers, but that is making code motion passes more > complicated than

----- Original Message ----- > From: "Jakob Stoklund Olesen" <stoklund at 2pi.dk> > To: "Akira Hatanaka" <ahatanak at gmail.com> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>, "Hal Finkel" <hfinkel at anl.gov> > Sent: Tuesday, March 26, 2013 12:40:44 PM > Subject: Re: [LLVMdev] [PATCH]

On Thu, Jun 27, 2013 at 9:50 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote: > On Jun 26, 2013, at 4:18 PM, Eric Christopher <echristo at gmail.com> wrote: > > > So inverting it so that MI contains LLVM IR instead of the other way > > around? Then we'd need a serialization format for MI that happened to > > include a way of serializing LLVM IR within.