search for: dagisel

..., 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 > > http://llvm.org/docs/TableGen/BackEnds.html > > That's not what I meant. There are some parts of that doc that are > redundant with what we have already on http://llvm.org/docs/TableGen/, > so just adding a link wouldn't help peopl...

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 it could be factored into the current docs, > so as to not du...

It seems that Tablegen is generating intrinsic ID's off by in DAGISel.inc In DAGISel.inc, I have the following pattern: int64_t CN1 = Tmp0->getZExtValue(); // Pattern: (intrinsic_w_chain:f32 103:iPTR, GPRF32:f32:$src0, GPRF32:f32:$src1, GPRF32:f32:$src2) // Emits: (MACRO_FMA_f32:f32 GPRF32:f32:$src0, GPRF32:f32:$src1, GPRF32:f32:$src2) // Pa...

Hi all! There is doc about tglben backends: http://llvm.org/docs/TableGen/BackEnds.html May be should to add link at https://github.com/draperlaboratory/fracture/wiki/How-TableGen%27s-DAGISel-Backend-Works I remember when I first met the LLVM it would be very useful. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140603/b9cb112f/attachment.html>

Hi, Currently, TableGen generates all the instruction selection functions (in the .inc file) as if they were top-most functions. To make them members of their corresponding SelectionDAGISel derivative, each target has to include the .inc file directly into the body of the class: --- FooDAGISel.inc --- void SelectCode(Node *N) { // 1E6 lines of pattern matching code } ... ---------------------- --- FooISelDAGToDAG.cpp --- class FooDAGToDAGISel : public SelectionDAGISel { #include...

Are you using isTarget = 1 in your intrinsics file? On Apr 14, 2009, at 6:34 PM, Villmow, Micah wrote: > It seems that Tablegen is generating intrinsic ID’s off by in > DAGISel.inc > > In DAGISel.inc, I have the following pattern: > int64_t CN1 = Tmp0->getZExtValue(); > > // Pattern: (intrinsic_w_chain:f32 103:iPTR, GPRF32:f32:$src0, > GPRF32:f32:$src1, GPRF32:f32:$src2) > // Emits: (MACRO_FMA_f32:f32 GPRF32:f32:$src0, GPRF32:f32:$src1,...

I thought I'd share a little bit of progress I made this weekend. I've gotten the first interesting test-case (a simple switch) through hyperblock-based DAGISel, and there's a pretty picture too! Each part of the switch is emitted directly into the DAG, rather than being deferred. This is the function: define i32 @foo(i32 %x, i32 %z) nounwind { entry: switch i32 %x, label %UnifiedReturnBlock [ i32 0, label %bb...

...s a lot of smarts and peepholes, because some JIT users had it as the main optimizing selector for a while. In that sense, it's a pretty aggressive target that IMO we don't have to match. > * FastISel doesn't seem to handle functions with switch statements, so it > falls back to DAGISel. DAGISel produces code that's a lot better than > GlobalISel for switch statement at -O0. I'm not sure if we need to do > something here before enabling GlobalISel by default. I'm thinking we may > need to add a smarter way to lower switch statements rather than just a > cas...

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 MatcherTable is selected but in the...

I've kicked off a run to compare "-O0 -g" versus "-O0 -g -mllvm -global-isel -mllvm -global-isel-abort=2". I've selected the test-suite (albeit a version which is a couple of months old now) and a few short-running proprietary benchmarks to get data back quickly for an initial feel of where things are. This was running on Cortex-A57 AArch64 Linux. I saw one assertion

...e inconsistent > filenames are a > bit confusing. Perhaps somebody should rename the lot of them? Sure, I'd support renaming them to <target>TargetLowering.cpp etc. > The same goes for <Target>ISelDAGToDAG.cpp, which defines a class > called > <Target>DAGToDAGISel. The DAGToDAG suffix is actually a pretty old historical artifact at this point. It would be better to rename the classes and files to <target>DAGISel. -Chris

...ro.html http://llvm.org/docs/TableGen/index.html http://llvm.org/docs/TableGen/BackEnds.html http://llvm.org/docs/CodeGenerator.html) Although not (really) about TableGen, I found a good paper talking about the instruction selection in LLVM: http://llvm.org/pubs/2008-CGO-DagISel.pdf . Thank you, Alex

...nk that the TargetLowering classes have anything to do with instruction selection [any more?]). However, the inconsistent filenames are a bit confusing. Perhaps somebody should rename the lot of them? The same goes for <Target>ISelDAGToDAG.cpp, which defines a class called <Target>DAGToDAGISel. Gr. Matthijs -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20081201/241b3ef7/attachment.sig>

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 used(Correct me if I'm wrong), introduce an selection algorithm for DAG instead of tree matching. My question is, according to the pa...

...stead of SEME region and how are you forming the blocks? Evan On Apr 20, 2008, at 9:59 PM, Christopher Lamb wrote: > I thought I'd share a little bit of progress I made this weekend. > I've gotten the first interesting test-case (a simple switch) > through hyperblock-based DAGISel, and there's a pretty picture too! > Each part of the switch is emitted directly into the DAG, rather > than being deferred. > > This is the function: > define i32 @foo(i32 %x, i32 %z) nounwind { > entry: > switch i32 %x, label %UnifiedReturnBlock [ >...

..., you’re right. The problem with ABI is if you are consistently wrong, then you won’t notice :). I’m wondering if since then on your side you did any testing around ABI compatibility? E.g. building software where you semi-randomly build some functions through GlobalISel and some functions through DAGISel? Justin will look into that. Clang has utility script for that utils/ABITest. Given we will only be able to check iOS ABI, you may want to follow the same kind of validation on your side. I let you sync up with Justin for the method. Thanks Quentin & Justin! I had a brief look at utils/ABIT...

...not doing this optimization sounds sensible to me. Now, I would say that the same remark as the previous bullet point apply: we shouldn’t do it unless it gets in the way of running/debugging the program. > * FastISel doesn’t\ seem to handle functions with switch statements, so it falls back to DAGISel. DAGISel produces code that's a lot better than GlobalISel for switch statement at -O0. I'm not sure if we need to do something here before enabling GlobalISel by default. I'm thinking we may need to add a smarter way to lower switch statements rather than just a cascaded sequence of co...

...lared in the *.td file, there is no information pertaining to which of the results should be used by the parent node. Since only tree-shaped patterns are allowed, SelectionIDAG must somehow decide which of the results are to be used by the parent node. And this decision is taken at lines 869-870 in DAGISelMatcherGen.cpp: ... unsigned FinalNumOps = InstOps.size() + NumSubOps; while (InstOps.size() < FinalNumOps) { const TreePatternNode *Child = N->getChild(ChildNo); unsigned BeforeAddingNumOps = InstOps.size(); EmitResultOperand(Child, InstOps); ass...

...012 3:35 PM To: Villmow, Micah Cc: LLVM Developers Mailing List Subject: Re: [LLVMdev] Tablegen to match a literal in an instruction Micah, I don't see anything wrong with this offhand. Have you tried getting the debug output from llc -debug, and matching it up with the state machine in your DAGISel.inc to see at what step the auto-generated matcher is failing to match your and-with-immediate? -Owen On Apr 19, 2012, at 3:07 PM, "Villmow, Micah" <Micah.Villmow at amd.com<mailto:Micah.Villmow at amd.com>> wrote: I am trying to make some modifications to our code generat...

...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 Copen Goldstein. "Near-optimal instruction selection on >> dags."), which is also said to be the algorithm LLVM currently used(Correct >> me if I'm wrong), introduce an selection algorithm for DAG instead of tree >> matching....