search for: combine1

...*int a, b;int main() {a=10;b=10;return a+b;}* Compiled with clang command to produce test.ll file which is attached below, *$clang -cc1 test.c -emit-llvm* Now If I want to run with my own target for selection with *llc* with command as follow getting error, *COMMAND:$ ./llc -view-dag-combine1-dags -march=toy -relocation-model=pic -filetype=asm ~/test.ll ERROR:./llc: /home/varun/test.ll:14:18: error: expected comma after load's type %2 = load i32* @a, align 4 ^* Please Help me with It. Thanks and Regards Varun -------------- next part -------------- An HTML attachme...

...=1] %tmp3 = load double* %x.addr ; <double> [#uses=1] store double %tmp3, double addrspace(11)* %tmp2 br label %ifend ifend: ; preds = %ifthen, %entry ret void } With the above kernel run through llc with -march=x86 -view-dag-combine1-dags I still see the ogt as the comparison operation, but when I run it with llc -march=x86 -view-legalize-dags the ogt node has been transformed into a ule. So, my question is, how do I get llvm to stop doing invalid translation of comparison instructions? This problem affects my custom backen...

On Mon, Nov 10, 2008 at 3:06 PM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > With the above kernel run through llc with -march=x86 > -view-dag-combine1-dags I still see the ogt as the comparison operation, but > when I run it with llc -march=x86 -view-legalize-dags the ogt node has been > transformed into a ule. Okay... I can see that in the attached graph. > So, my question is, how do I get llvm to stop doing invalid translation of &gt...

Hi, I recently started helping with the LLVM AVR backend [1]. The AVR is an 8 bit core with pointer type i16. That makes pointers illegal in the SelectionDAG. As far as I understand it, it is the backends job to legalize these nodes by using the ReplaceNodeResults/LowerOperation callbacks. Is that about right? I have the feeling that the symbolic nodes carrying pointers, like FrameIndex are

...LLVM and make use of the debug output from llc. The SelectionDAG dumping features are especially interesting to me since I am looking for operation patterns that allow me to decide which custom instructions can be added to a processor in order to improve the performance. Providing a -view-dag-combine1-dags option (and its friends) to llc show the SelectionDAG nicely in a viewer. I was wondering about the reasoning behind this behavior. In my case it would be much more useful to just get the DOT files of these graphs in either the current location, or optionally at some user specified locati...

...serting on the following item. > > Cannot yet select: 017B8010: i32 = fneg 017B7E78 That seems strange... you definitely shouldn't be seeing an fneg with an i32 result. What sorts of changes have you made to the SPARC backend? Have you tried looking at the output of "llc -view-dag-combine1-dags" and "llc -view-legalize-dags" to see where exactly this node is getting introduced? > What I cannot figure out is why it is attempting to pattern match on an i32 > when there are no i32's in my test program. With the regular SPARC backend, what ends up happening is...

...o that solutions to these problems were more likely to happen! > > We maintain an out of tree backend for at least one target that has an i64 pointer type but for which i64 is illegal (much like AVR, 6502, etc). Unfortunately, the solution is extremely ugly; it lowers loads and stores during combine1 (before legalization), which is way less than ideal. It also uses 32-bit frameindexes (it treats the stack as 32-bit despite global pointers being 64-bit), so I don’t think that provides a usable template for a solution here, unfortunately. If it would help, one of the changes that we’ve made is t...

...re sufficient registers. It'll need to be extended some, because it calls llvm_unreachable() when it runs out of registers, which is the behavior we're trying to avoid here :-). If you're not familiar with the SelectionDAG IR, feel free to ask questions. I recommend using the -view-dag-combine1-dags option, which provides a visualization of the SelectionDAG for each basic block immediately after it has been constructed, to get an idea of what's being built. > > Anything you care to tell me would be welcome. I will be starting on > this today or tomorrow. Ok, let me know if...

> I recently made a major reorganization of the calling-convention > lowering code which cleared away one of the major obstacles to > doing this within codegen. > > Dan So what was the obstacle, and how was it cleared? And how do you see the large struct return working in codegen? Anything you care to tell me would be welcome. I will be starting on this today or tomorrow.

...ent was scrubbed... Name: legalize-dags.pdf Type: application/pdf Size: 46606 bytes Desc: legalize-dags.pdf URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200327/7bc9722e/attachment-0002.pdf> -------------- next part -------------- A non-text attachment was scrubbed... Name: dag-combine1.pdf Type: application/pdf Size: 45602 bytes Desc: dag-combine1.pdf URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200327/7bc9722e/attachment-0003.pdf>

So, I have this small test program that I figured would cause no problems but want to test all the various data types and operations with my modified sparc backend. I've been working on LLVM for about 3 days now, so this might be a problem with not knowing enough yet, so thanks for bearing with me. The code that I based my example off of is compiled to LLVM-IR from: void

...serting on the following item. > > Cannot yet select: 017B8010: i32 = fneg 017B7E78 That seems strange... you definitely shouldn't be seeing an fneg with an i32 result. What sorts of changes have you made to the SPARC backend? Have you tried looking at the output of "llc -view-dag-combine1-dags" and "llc -view-legalize-dags" to see where exactly this node is getting introduced? Thanks I'll get this a try. I've made quite a few changes, introduced many new instructions and formats for my backend and working on getting the various data types to work with all the...

Hi I would like to view the various dags being output during codegen. Unfortunately, I am not seeing the files being dumped. I will really appreciate if someone can help me here llc switch.bc -f -view-dag-combine1-dags ( i tried -view-isel-dags, -view-sched-dags as well) Writing '/tmp/llvm_zbbAKM/dag.main.dot'... done. Writing '/tmp/llvm_G4rLKf/dag.main.dot'... done. Writing '/tmp/llvm_mv0TMI/dag.main.dot'... done. Writing '/tmp/llvm_adT8Ob/dag.main.dot'... done. Writing...

...operator! To sovle this problem, I tried "-march=sparcv9" (LLVM 3.1 release version), the same problem occured. sparcv9 is a 64-bit target so FrameIndex operator produces i64 data, and it seems v9 subtarget did not handle this well. Then I tried llc option "-march=x86-64 -view-dag-combine1-dags". It works OK. FrameIndex produces i64 in x86-64, but this subtarget can handle the problem well. So I guess hacking x86-64 backend will help me to find a solution. But I need more clues. Can someone tell me where to start? Best regards. -- 杨勇勇 (Yang Yongyong)

...icantly better than greedy; in practice most optimization goals seem to be representable through heuristics on the regular selection algorithm, at least for real machines. Additionally, I kind of suspect that there is far more to gain from better transformations during instruction lowering (e.g. in Combine1/Legalize/Combine2) than from better ordering in Select(). —escha > On Mar 28, 2018, at 3:31 AM, Ivan Kulagin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Is the algorithm described in the article "Near-Optimal Instruction > Selection on DAGs > (https://llvm.org/...

...ot;false" } !llvm.module.flags = !{!0} !llvm.ident = !{!1} !0 = !{i32 1, !"wchar_size", i32 2} !1 = !{!"clang version 6.0.0 (trunk 315731) (llvm/trunk 316278)"} So far, so good. Now, when I try to compile this: build/bin/llc -march tms9900 -filetype=asm foo.bc -view-dag-combine1-dags -debug -O0 ... Initial selection DAG: BB#0 'dothis:entry' SelectionDAG has 17 nodes: t0: ch = EntryToken t2: i16,ch = CopyFromReg t0, Register:i16 %vreg0 t6: i64 = Constant<0> t8: ch = store<ST2[%a.addr]> t0, t2, FrameIndex:i64<0>, undef:i64 t4: ch = Co...

I can't think of any workaround? this optimization eliminates so much information that if we want to retrieve back, it will take a lot of processing and may not necessarily be able to retrieve the lost information for all cases. Besides, why does the generic part of llvm have to force an optimization that is counter productive to some targets? If there are other phases that do the same

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

Hi All, In XCore backend, I saw “ …... EVT VT = Op.getValueType(); SDValue Data = DAG.getNode(XCoreISD::CRC8, DL, DAG.getVTList(VT, VT), Op.getOperand(1), Op.getOperand(2) , Op.getOperand(3)); SDValue Crc(Data.getNode(), 1); SDValue Results[] = { Crc, Data }; return DAG.getMergeValues(Results, 2, DL); “ which is used to lower an

Hello all, I recently foudn myself wanting to view the basic blocks in the selection DAG as pure DAGs - so just as a list of edges, with no other information. I added the below code to the start of the " void SelectionDAGISel::CodeGenAndEmitDAG()" function. It creates a separate txt file for each basic block and gives a list of edges between nodes. The segment of code is below -