search for: allarddegrandmaison

...e to a valid register > >> allocation for your test case. Please try it out and let me know if it > >> works for you. > >> > >> Cheers, > >> Lang. > >> > >> On Tue, Mar 27, 2012 at 5:05 AM, Arnaud de Grandmaison > >> <arnaud.allarddegrandmaison at parrot.com<mailto: > arnaud.allarddegrandmaison at pa > >> rrot.com>> wrote: Hi Lang, > >> > >> I have reduced the testcase as much as possible. The log of the run and > the > >> dumped graphes are attached. > >> > >> Cheers, &...

...cost solution > for the test case you sent me. This should translate to a valid register > allocation for your test case. Please try it out and let me know if it > works for you. > > Cheers, > Lang. > > On Tue, Mar 27, 2012 at 5:05 AM, Arnaud de Grandmaison > <arnaud.allarddegrandmaison at parrot.com<mailto:arnaud.allarddegrandmaison at pa > rrot.com>> wrote: Hi Lang, > > I have reduced the testcase as much as possible. The log of the run and the > dumped graphes are attached. > > Cheers, > -- > Arnaud de Grandmaison > > On Tuesday, March...

...t case you sent me. This should translate to a valid register >> allocation for your test case. Please try it out and let me know if it >> works for you. >> >> Cheers, >> Lang. >> >> On Tue, Mar 27, 2012 at 5:05 AM, Arnaud de Grandmaison >> <arnaud.allarddegrandmaison at parrot.com<mailto:arnaud.allarddegrandmaison at pa >> rrot.com>> wrote: Hi Lang, >> >> I have reduced the testcase as much as possible. The log of the run and the >> dumped graphes are attached. >> >> Cheers, >> -- >> Arnaud de Grandmaison...

...r153958 applied the solver now finds a zero-cost solution for the test case you sent me. This should translate to a valid register allocation for your test case. Please try it out and let me know if it works for you. Cheers, Lang. On Tue, Mar 27, 2012 at 5:05 AM, Arnaud de Grandmaison < arnaud.allarddegrandmaison at parrot.com> wrote: > Hi Lang, > > I have reduced the testcase as much as possible. The log of the run and the > dumped graphes are attached. > > Cheers, > -- > Arnaud de Grandmaison > > On Tuesday, March 27, 2012 01:20:35 Lang Hames wrote: > > Hi Arnaud, &...

...ing the "-regalloc=pbqp -pbqp-dump-graphs > -debug-only=regalloc" options. I'll need to take a look at the last > graph dumped before the assertion is triggered. > > Cheers, > Lang. > > On Mon, Mar 26, 2012 at 7:35 AM, Arnaud de Grandmaison > > <arnaud.allarddegrandmaison at parrot.com> wrote: > > Hi Lang, > > > >> From memory your target is not public, so I won't be able to reproduce > >> the crash myself. Is that correct? > > > > Correct. > > > >> If that's the case, I could add functionality t...

I doubt you needed to add cfe-dev here. Sorry I hadn't seen this, this seems like an easy and simple deficiency in the IR intrinsic for memcpy. See below. On Sun, Jan 20, 2013 at 1:42 PM, Arnaud de Grandmaison < arnaud.allarddegrandmaison at parrot.com> wrote: > define void @test(i16 zeroext %a) nounwind uwtable { > %r.sroa.0 = alloca i16, align 2 > %r.sroa.1 = alloca i16, align 2 > store i16 %a, i16* %r.sroa.0, align 2 > store i16 1, i16* %r.sroa.1, align 2 > %r.sroa.0.0.load3 = load volatile i16* %r...

...01/20/2013 10:56 PM, Chandler Carruth wrote: > I doubt you needed to add cfe-dev here. Sorry I hadn't seen this, this > seems like an easy and simple deficiency in the IR intrinsic for > memcpy. See below. > > On Sun, Jan 20, 2013 at 1:42 PM, Arnaud de Grandmaison > <arnaud.allarddegrandmaison at parrot.com > <mailto:arnaud.allarddegrandmaison at parrot.com>> wrote: > > define void @test(i16 zeroext %a) nounwind uwtable { > %r.sroa.0 = alloca i16, align 2 > %r.sroa.1 = alloca i16, align 2 > store i16 %a, i16* %r.sroa.0, align 2 >...

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...

...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 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...

...ral hazards (this should not happen so often...). Btw, you didn't reply on the mailing list... is it just an omission ? Getting it on the mailing list might be helpful for the llvm community ;) Best regards, Damien On Fri, Feb 11, 2011 at 1:30 AM, Arnaud Allard de Grandmaison <Arnaud.AllardDeGrandMaison at dibcom.com<mailto:Arnaud.AllardDeGrandMaison at dibcom.com>> wrote: Hi Damien, We also found this issue; our way of solving it was to add a pass after postRAScheduler to handle those inter MBB hazards. The postRAHazardRecognizer maintains a hazard state inside the basic block, and depe...

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

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_...

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

...gh the allocator with this patch applied, passing the "-regalloc=pbqp -pbqp-dump-graphs -debug-only=regalloc" options. I'll need to take a look at the last graph dumped before the assertion is triggered. Cheers, Lang. On Mon, Mar 26, 2012 at 7:35 AM, Arnaud de Grandmaison <arnaud.allarddegrandmaison at parrot.com> wrote: > Hi Lang, > >> From memory your target is not public, so I won't be able to reproduce >> the crash myself. Is that correct? > Correct. > >> If that's the case, I could add functionality to dump the PBQP graphs >> during allocatio...

...ginal Message----- From: Eli Friedman [mailto:eli.friedman at gmail.com] Sent: Sunday, March 13, 2011 11:08 PM To: Arnaud Allard de Grandmaison Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] IndVarSimplify too aggressive ? 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_...

Hi Lang, > From memory your target is not public, so I won't be able to reproduce > the crash myself. Is that correct? Correct. > If that's the case, I could add functionality to dump the PBQP graphs > during allocation. I think they should give me enough information to > debug the issue. Would you be able to share the PBQP graphs? I can share the pbqp graph if you send

I can't think of a better way to do this, so I think it's ok. I also submitted a complementary patch on llvm-commits clarifying volatile semantics. -Andy On Jan 28, 2013, at 8:54 AM, Arnaud A. de Grandmaison <arnaud.allarddegrandmaison at parrot.com> wrote: > Hi All, > > In the language reference manual, the access behavior of the memcpy, > memmove and memset intrinsics is not well defined with respect to the > volatile flag. The LRM even states that "it is unwise to depend on it". > This forces o...

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