similar to: RFC: Splitting <Target>DAGISel.inc into declarations and definitions

Thanks Ahmed and also Alex for your replies. This is more or less what I was realising, but it is a great confidence booster to know that it is the correct way also. I can replace all of my various 'Select*' specialisations with version that use 'ReplaceNode/SelectCode' and return 'void', but what about the places where I currently call 'Select(N)' directly?

It occurred to me that instead of the various breakout 'Select*' functions returning the 'SDNode*' result, maybe I should be calling: ReplaceNode(N, newValue); return; or: SelectCode(N); return; Perhaps? MartinO From: Martin J. O'Riordan [mailto:martin.oriordan at movidius.com] Sent: 28 June 2016 16:49 To: 'LLVM Developers'

"Martin J. O'Riordan" <martin.oriordan at movidius.com> writes: > Thanks Ahmed and also Alex for your replies. > > This is more or less what I was realising, but it is a great > confidence booster to know that it is the correct way also. I can > replace all of my various 'Select*' specialisations with version that > use

On Tue, Jun 28, 2016 at 8:53 AM, Martin J. O'Riordan via llvm-dev <llvm-dev at lists.llvm.org> wrote: > It occurred to me that instead of the various breakout ‘Select*’ functions > returning the ‘SDNode*’ result, maybe I should be calling: > > > > ReplaceNode(N, newValue); > > return; > > or: > > SelectCode(N); > > return; > > >

Is the algorithm described in the article "Near-Optimal Instruction Selection on DAGs (https://llvm.org/pubs/2008-CGO-DagISel.html)" really used in llvm instruction selection? I've studied implementation (SelectionDAGISel.cpp) and I see that instructions are selected by target specific MatcherTable generated by llvm-tblgen. In the implementation the first matching pattern from

Although I would like to track the LLVM head revisions regularly, unfortunately I only get the opportunity every couple of months or even every 6 month with a full release. This time I am updating from revision #262824 (8th March) so more than 3 months have elapsed. For the most part I have completed the changes I need to make, but I'm stuck on one change that is more significant than it

Hi, I'm new to LLVM and I'm doing research on factors of compilation time, especially instruction selection and scheduling. One of the academic papers I read, https://llvm.org/svn/llvm-project/www-pubs/trunk/2008-CGO-DagISel.pdf (Koes, David Ryan, and Seth Copen Goldstein. "Near-optimal instruction selection on dags."), which is also said to be the algorithm LLVM currently

Thanks for swift reply > Ahmed Bougacha <ahmed.bougacha at gmail.com> 於 2016年6月28日 下午8:11 寫道： > > On Tue, Jun 28, 2016 at 4:42 AM, Bekket McClane via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> Hi, >> I'm new to LLVM and I'm doing research on factors of compilation time, >> especially instruction

On Tue, Jun 28, 2016 at 4:42 AM, Bekket McClane via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Hi, > I'm new to LLVM and I'm doing research on factors of compilation time, > especially instruction selection and scheduling. One of the academic papers > I read, > https://llvm.org/svn/llvm-project/www-pubs/trunk/2008-CGO-DagISel.pdf (Koes, > David Ryan, and Seth

Hello, Im (trying) to write a backend for a simple 32bit processor architecture, with a single instruction format having no condition code registers. www.docm.mmu.ac.uk/STAFF/A.Nisbet/Sabre.pdf is the short 15 page document describing the architecture of Sabre. It is a Celoxica developed research/teaching processor, pages 5-8 contain relevant information for targetting it from a new compiler

On Tue, Jun 28, 2016 at 5:49 AM, Bekket McClane <bekket.mcclane at gmail.com> wrote: > Thanks for swift reply > > Ahmed Bougacha <ahmed.bougacha at gmail.com> 於 2016年6月28日 下午8:11 寫道： > > On Tue, Jun 28, 2016 at 4:42 AM, Bekket McClane via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > Hi, > I'm new to LLVM and I'm doing research on factors

Hi Ivan, Matcher table generation which is implemented in utils/DAGISelEmitter.cpp does use heusiristics like number of instructions which a pattern will cover, latency (not the one which Targets scheduling defines) while emitting the candidate patterns for a give dag node. Current implications may not be implication of algorithm in toto though. Thanks, Jatin On Wednesday, March 28, 2018, Ivan

LLVM performs a greedy, bottom-up instruction selection. At each step, it selects the pattern that will absorb the most nodes (roughly: the order can be tweaked by the target using AddedComplexity, which is often used to model the idea that a particular pattern is more profitable than it would otherwise appear). I don’t personally think there is that much to gain from an algorithm significantly

Hello, Tim, Thank you for your advice. Indeed, the problem with "LLVM ERROR: Cannot select" was a false predicate that should have been true. I solved the problem by simply making the C++ function implementing the TableGen predicate used in my store instruction (very similar to the selectIntAddrMSA predicate from the Mips back end) return true instead of false. But

Hello. I fixed the bug reported in the previous post on this thread (<<llvm::MemSDNode::MemSDNode(unsigned int, unsigned int, const llvm::DebugLoc&, llvm::SDVTList, llvm::EVT, llvm::MachineMemOperand*): Assertion `memvt.getStoreSize() <= MMO->getSize() && "Size mismatch!"' failed.>>) The problem with this strange error reported comes from

On Mon, 14 Apr 2008, [ISO-8859-1] Török Edwin wrote: >> Another question to ask, is why that function became so large in the >> first place [X86DAGToDAGISel::SelectCode(llvm::SDOperand)] >> We have inline limits, don't we? > > most of functions called by SelectCode get a -30000 cost reduction > because they are internal. > Even if Caller.size() is 40000, the

On Tue, Jun 3, 2014 at 7:30 AM, Renato Golin <renato.golin at linaro.org> wrote: > On 3 June 2014 14:10, Daniil Troshkov <troshkovdanil at gmail.com> wrote: > > The job is very simple: add link at page > > > https://github.com/draperlaboratory/fracture/wiki/How-TableGen%27s-DAGISel-Backend-Works > > into doc page > >

Segfault in EE->getPointerToFunction. I think it's blown the stack, gdb reports a never ending backtrace (below). I generate llvm assembly and parse/verify OK. Attached is the assembly. It is the smallest example generated that causes the segfault. If this EE uses a recursive function (??), it seems an inherent limitation in how big llvm functions can be. Simon. gdb backtrace: #0

Evan Cheng wrote: > On Apr 13, 2008, at 1:28 PM, Török Edwin wrote: > > >> Hi, >> >> In PR2193 LiveVariables runs out of memory on a 512M limit, after >> processing 11557 basicblocks. >> VirtRegInfo has ~180000 entries with ~700 bytes each. >> If I give it more memory (1.5G) it runs out of memory in LiveInterval. >> > > Some of the

I agree, but I have no experience with LLVM doc. The job is very simple: add link at page https://github.com/draperlaboratory/fracture/wiki/How-TableGen%27s-DAGISel-Backend-Works into doc page http://llvm.org/docs/TableGen/BackEnds.html But how I can do it? On Tue, Jun 3, 2014 at 4:41 PM, Renato Golin <renato.golin at linaro.org> wrote: > Hi Daniil, > > Those look great! I think