similar to: [LLVMdev] Leaks in PBQPBuilderWithCoalescing::build ?

Oooh. Neat. Thanks Dave. Please go ahead and commit that. Arnaud - I have no idea whether Dave's patch will help with this bug, but it's certainly worth testing. - Lang. On Wed, Sep 10, 2014 at 4:10 PM, David Blaikie <dblaikie at gmail.com> wrote: > While I'm not sure where the leak is, using some pre-canned memory > management might help... > > Attached is a

Hi Arnaud, Thanks for following up with that and sorry for the breakage. Couple of comments: MachineLoopInfo *MLI; + RegScavenger *RS; Would it make sense to use a unique_ptr here? That should eliminate the need of having explicit deletes. +; RUN: llc -mtriple=aarch64-linux-gnu -o - %s Add -enable-shrink-wrap=true and a second RUN line with -enable-shrink-wrap=false. Then add check lines

Hi Quentin, After shrink-wrapping was enabled as default on AArch64, llc has a seg fault when compiling the attached .ll file on AArch64. My command is llc -mcpu=cortex-a57 bug.ll Best, Haicheng -------------- next part -------------- A non-text attachment was scrubbed... Name: bug.ll Type: application/octet-stream Size: 8983 bytes Desc: not available URL:

I honestly do not know how to fix that --- I would otherwise I've committed a fix. I've been able to hack it locally exploiting the very same lit limitation then the one we're stumbling on (i.e it does not resolve dependency correctly and only pick-up the first constraint). You need to make sure the Flask constraint is seen first, even before using the requirements.txt so on the

I think that will work. We should actually fix it to work with .11. It is a dot release, the changes are minor. Sent from my iPhone > On May 31, 2016, at 6:34 AM, Kristof Beyls via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I hope I've fixed this properly just now in http://llvm.org/viewvc/llvm-project?view=revision&revision=271274. > Fingers crossed that the

I hope I've fixed this properly just now in http://llvm.org/viewvc/llvm-project?view=revision&revision=271274. Fingers crossed that the bots will come back now... On 30 May 2016, at 21:01, Arnaud De Grandmaison <Arnaud.DeGrandmaison at arm.com<mailto:Arnaud.DeGrandmaison at arm.com>> wrote: I honestly do not know how to fix that --- I would otherwise I've committed a fix.

> -----Original Message----- > From: Hal Finkel [mailto:hfinkel at anl.gov] > Sent: 04 November 2014 17:16 > To: Arnaud De Grandmaison > Cc: LLVM Developers Mailing List > Subject: Re: [LLVMdev] lifetime.start/end clarification > > ----- Original Message ----- > > From: "Arnaud A. de Grandmaison" <arnaud.degrandmaison at arm.com> > > To:

> > * This claim is only partially tested, but I'm running the allocator right > now with the base constraints plus an extension which adds coalescing costs > and it's just passed CINT2006 without error. Not bad given that the > coalescing extension only took a couple of hours to write > Following up on this footnote - The PBQPBuilderWithCoalescing builder is now in the

Hi Lang, While working on improving the debug dumps of the PBQP graphs, I found out that we can have some edges between nodes which belong to totally disjoint register classes (for example, on AArch64, this would be an int and a floating point register). Although it is true those 2 registers interferes, in the sense they are alive at the same time, they never have any physical interference,

Both approaches are not exclusive. I would even think it makes sense to have a pre-split pass to prepare the graph, with a global view, and later on use use trySplit (or an equivalent) to handle the local coloring issues. From: Quentin Colombet [mailto:qcolombet at apple.com] Sent: 09 March 2015 23:08 To: Lang Hames Cc: Jonas Paulsson; llvmdev at cs.uiuc.edu; Arnaud De Grandmaison Subject:

% clang -S -O3 -mcpu=cortex-a57 -ffast-math -Rpass-analysis=loop-vectorize dot.c dot.c:15:1: remark: loop not vectorized: value that could not be identified as reduction is used outside the loop [-Rpass-analysis=loop-vectorize] } ^ dot.c:15:1: note: could not determine the original source location for :0:0 I found “llvm-as < /dev/null | llc -march=aarch64 -mattr=help” which listed a

So far, all I have tried is -O3 and with & without "-mcpu=cortex-a57". I'm new to LLVM so I'm not familiar with what optimization flags are available. I tried poking around in the LLVM documentation but haven't found a definitive list. The clang man page is skimpy on details. From: Arnaud A. de Grandmaison [mailto:arnaud.degrandmaison at arm.com] Sent: Monday, February

Renato, Kristof, I confirm this is due to the latest Flask --- Flask-0.11 was released this weekend --- and for some unknown (to me at least) reason, although LNT's requirements.txt pins Flask to version 0.10.1, pip installs Flask-0.11. Forcing Flask to 0.10.1 gets the situation back to normal. Reading pip's documentation makes me think it's not able to resolve dependencies

Hi, I have worked a little on the PBQP register allocator, and it is quite clear (at least to me) that it is not even a serious alternative to RegAllocGreedy at the moment, due to the poor handling of spilling. As Arnaud wrote below, it is not optimizing spilling at all, but rather just spills anything that does not get an assignment. The result is a lot more spill/reload instructions than

Hi Quentin, Jonas, Splitting fits in with PBQP reasonably well, at least conceptually. The PBQP graph is designed to be mutable, so there is no problem with updating it when splitting. As I see it, there are two logical places to integrate splitting into PBQP: 1) Split during spilling -- If a PBQP solution selects the spill option for a node, rather than spill immediately, split the interval

On 30 May 2016 at 12:25, Arnaud De Grandmaison <Arnaud.DeGrandmaison at arm.com> wrote: > I confirm this is due to the latest Flask --- Flask-0.11 was released this > weekend --- and for some unknown (to me at least) reason, although LNT's > requirements.txt pins Flask to version 0.10.1, pip installs Flask-0.11. > Forcing Flask to 0.10.1 gets the situation back to normal. Do

The LRM (http://llvm.org/docs/LangRef.html#llvm-lifetime-start-intrinsic) essentially states that: - ptr is dead before a call to "lifetime.start size, ptr" - ptr is dead after a call to "lifetime.end size, ptr" This is all good and fine, and the expected use case is that all "lifetime.end size, ptr" markers are matched with a preceding "lifetime.start

Hi All, I've just committed some changes to the PBQP allocator which are designed to make it easier to implement custom register allocation constraints. This is a quick summary of those changes, and of the status of the PBQP allocator in general. First a quick bit of background: The PBQP allocator is based on ideas described in [1]. I implemented this algorithm (with the improved heuristic

Hi Arnaud, The conservatively allocatable test is supposed to check two conditions, either of which would be sufficient to make a node allocatable: (1) There exists some register that is not aliased by any register option for any neighbor. This is the "safe row" test. It is straightforward, but likely to fire only rarely. (2) The sum of the maximum number of registers aliased by any

> A node should never be put into the conservatively allocatable list if there is a chance of it spilling. I can understand why the logic of NodeMetadata::isConservativelyAllocatable is necessary for the node to be allocatable, but I have not been able to convince myself this is sufficient, especially when the node degree > available registers. Cheers, Arnaud From: