similar to: [LLVMdev] DiBcom is hiring !

Ooops, you are right. Just forgot to CC the mailing list. Thanks for noticing it,, -- Arnaud de Grandmaison ________________________________________ From: Damien Vincent [damien.llvm at gmail.com] Sent: Saturday, February 12, 2011 3:57 AM To: Arnaud Allard de Grandmaison Subject: Re: [LLVMdev] Hazard recognizers & basic blocks Merci ! I was also planning to add a second pass to verify these

On Tue, Oct 19, 2010 at 12:19 AM, Arnaud Allard de Grandmaison <Arnaud.AllardDeGrandMaison at dibcom.com> wrote: >> But if the usage was in a loop it would be better (at the cost of >> register pressure) to materialise 5 into a register outside of the >> loop and use the register repeatedly in the loop. > > Bouncing on this subject: you can not know before isel is

Hi Arnaud, That sounds great. I look forward to seeing a patch. You may also look forward to big performance improvements in the PBQP allocator: I'm working on updates which will improve compile speeds and massively reduce memory use. Regards, Lang. On Tue, Jun 7, 2011 at 7:02 PM, Arnaud Allard de Grandmaison < Arnaud.AllardDeGrandMaison at dibcom.com> wrote: > > I also

Thanks Eli, After digging thru mail archives & bugzilla, it seems fixing properly this issue would require a major change in the selectionDAG code --- to have it operate on a per function basis instead of per basic-block. This however, does not seem to be the only issue. The following C code does not produce an efficicient assembly sequence either. extern void f(unsigned long long v); void

Attached is a small patch to allow users of the PBQP allocator to optionally insert a custom pass. I believe it can be usefull to other users of the pbqp. I used it to undo some of the coalescer work, and make sure that I have different virtual registers, inserting a copy if necessary, to build a pair. I noticed an unexpected --- to me at least --- behaviour of the allocator. I have some

On Sun, Mar 13, 2011 at 5:01 PM, Arnaud Allard de Grandmaison <Arnaud.AllardDeGrandMaison at dibcom.com> wrote: > Hi all, > > The IndVarSimplify pass seems to be too aggressive when it enlarge the induction variable type ; this can pessimize the generated code when the new induction variable size is not natively supported by the target. This is probably not an issue for x86_64,

I also considered this approach, but did not want to dive in the constraint handling for now. The PBQP path seemed easier at first sight --- and was easy to setup. And I always wanted to give a try to the pbqp :) I will add the hook to the pbqp and propose a patch if this looks clean enough. Thanks, -- Arnaud de Grandmaison -----Original Message----- From: Jakob Stoklund Olesen

Hi Dan, >Did the code in the tutorial work at some point? Offhand, I wouldn't expect >any of my recent changes to have affected this. I'm reluctant to fix this >without understanding how the original code was intended to work. The code works, but not as shown in the tutorial. In the tutorial, it shows that multiple calls to pure functions (sin, cos) can be optimized. Without the

Hi all, The IndVarSimplify pass seems to be too aggressive when it enlarge the induction variable type ; this can pessimize the generated code when the new induction variable size is not natively supported by the target. This is probably not an issue for x86_64, which supports natively all types, but it is a real one for several embedded targets, with very few native types. I attached a patch to

Hi, Here is a little patch to have cmake detect dotty, and if this was the case, update the HAVE_DOTTY and LLVM_PATH_DOTTY defines in include/llvm/Config/config.h. This should apply cleanly on TOT. Best regards, -- Arnaud de Grandmaison -------------- next part -------------- An HTML attachment was scrubbed... URL:

> But if the usage was in a loop it would be better (at the cost of > register pressure) to materialise 5 into a register outside of the > loop and use the register repeatedly in the loop. Bouncing on this subject: you can not know before isel is over if the constants have to materialize into registers or not, as this is really dependent on the target's instruction set. Do we have

Rob, I can reproduce the behaviour you observe using llvm top-of-tree. I will try to look into it. Best regards, -- Arnaud de Grandmaison -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Rob Pieke Sent: Monday, November 15, 2010 4:27 PM To: Duncan Sands; llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Optimization of calls to

Hi, 1. This instruction is not selected automatically by the instruction selector. The instruction combine / select stages insert registercopies, and they are expanded later on by the copyRegToReg() function provided by the MSP430InstrInfo to this MOV16rr. 2. ReMaterializable means there is no need to find a way to preserve the value in a register : the instruction can be just be reissued

I am working on a target which has some structural hazards. To detect these hazards, I implemented a sub-class of PostRAHazardRecognizer. PostRAHazardRecognizer resets the hazard state on a basic block basis. So, how to detect hazards that may occur between the end of a basic block and the beginning of another basic block ? Thanks ! -------------- next part -------------- An HTML

Hi Ether, The detection for graphviz / dotty / ... has been added recently to llvm cmake. It should work properly if those tools are available in the PATH. The related svn commits are : 86153, 86547 and 86644. Those commits are not present in llvm release <= 2.6, but they are straight forward to apply. Best regards, -- Arnaud de Grandmaison -----Original Message----- From: llvmdev-bounces at

Hi Arnaud, I'm glad to hear that your test case is working. I however still get my wrong allocation in some non trivial cases : the > pairing constraint is not fulfilled. > > I have tried to modify the 'ensure pairable' pass (the pass undoing some > of the coalescer's work) to always insert register copies for > instructions with the pairable constraint, instead of

Hi Lang, The assert is not triggered any longer on my testcases :) I however still get my wrong allocation in some non trivial cases : the pairing constraint is not fulfilled. I have tried to modify the 'ensure pairable' pass (the pass undoing some of the coalescer's work) to always insert register copies for instructions with the pairable constraint, instead of being smart and

We're currently hiring at Okcupid. Software Engineer ----------------- Location: New York, NY (Chelsea / Union Square, 20-30 minutes from other boroughs and NJ). OkCupid has several open Software Engineer positions for which we seek an outstanding full-time technologists. Candidates should expect to work closely with the CTO on many critical technology issues, but the primary

Hi Lang, Thanks a lot for taking time to look into this. I will test the fix soon and let you know the results. Cheers, -- Arnaud de Grandmaison On Tuesday, April 03, 2012 17:30:33 Lang Hames wrote: > Hi Arnaud, > > Apologies for the delayed reply. > > Thank you for the excellent test case - it exposed a subtle bug in the > colorability heuristic. This has been fixed in

Oops. Forgot the mailing list in the reply. -- Arnaud de Grandmaison ________________________________________ From: Arnaud Allard de Grandmaison Sent: Thursday, June 03, 2010 9:57 PM To: Jakob Stoklund Olesen Subject: RE: [LLVMdev] Unused argument registers can not be reused ? I have finally been able to make some progress : the bug has been introduced/revealed by svn commit #95493, which enabled