similar to: [LLVMdev] DAG optimization and lowering algorithm

On Mon, Feb 6, 2012 at 11:54 PM, Demikhovsky, Elena <elena.demikhovsky at intel.com> wrote: > Hi, > > I'm trying to build code for very short function and I encounter with a problem (or bug) in DAG selection algotithm. > I have a node that was created in Combine(BeforeLegalizeTypes) and should be optimized in Combine(AfterLegalizeTypes). But LegalizeTypes() did not change

At the beginning, I have the following chain: LOAD -> TRUNCATE -> ZERO_EXTEND. After Combine(BeforeLegalizeTypes) the optimization of ZERO_EXTEND gives me the new chain LOAD -> ANY_EXTEND -> AND. I want to optimize ANY_EXTEND but is not analyzed in the same Combine(). Combine(AfterLegalizeTypes) is no called at all. - Elena -----Original Message----- From: Eli Friedman

Per subject, this patch adding an additional pass to handle vector operations; the idea is that this allows removing the code from LegalizeDAG that handles illegal types, which should be a significant simplification. There are still some issues with this patch, but does the approach look sane? -Eli -------------- next part -------------- Index: lib/CodeGen/SelectionDAG/LegalizeVectorOps.cpp

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 -

On Tue, Feb 7, 2012 at 12:38 AM, Demikhovsky, Elena <elena.demikhovsky at intel.com> wrote: > At the beginning, I have the following chain: LOAD -> TRUNCATE -> ZERO_EXTEND. > After Combine(BeforeLegalizeTypes) the optimization of ZERO_EXTEND  gives me the new chain LOAD -> ANY_EXTEND -> AND. > > I want to optimize ANY_EXTEND but is not analyzed in the same Combine().

On Wed, May 20, 2009 at 1:19 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > Per subject, this patch adding an additional pass to handle vector > operations; the idea is that this allows removing the code from > LegalizeDAG that handles illegal types, which should be a significant > simplification.  There are still some issues with this patch, but does > the approach

Hi Sanjay, thanks for this information. I did get a little bit further with the patch. However, Hexagon gives me headaches. I tried to limit the scope of the patch to the BeforeLegalizeTypes phase and Hexagon still reaches the unreachable. Hexagon tries to split or widen a vector type for a node with custom lowering where the unreachable arises from inside TargetLowering::ReplaceNodeResults

Is VT a legal type on Hexagon? It looks like Hexagon may be setting SHL as Custom for every defined vector type. Try adding TLI.isTypeLegal(VT) too. ~Craig On Thu, Sep 21, 2017 at 10:06 PM, Haidl, Michael < michael.haidl at uni-muenster.de> wrote: > Hi Sanjay, > > thanks for this information. I did get a little bit further with the > patch. However, Hexagon gives me headaches.

There are multiple problems/questions here: 1. Make sure you've updated trunk to the latest rev before running update_llc_test_checks.py on lea-3.ll. Ie, I would only expect the output you're seeing if you're running the script on a version of that test file before r313631. After that commit, each RUN has its own check prefix, so there should be no conflict opportunity. 2. I

Hi Craig, protecting the transformation with: if (TLI.isTypeLegal(VT) && TLI.isOperationLegal(ISD::SUB, VT) && TLI.isOperationLegal(ISD::ADD, VT) && TLI.isOperationLegal(ISD::SHL, VT) && TLI.isOperationLegal(ISD::SRA, VT)) { shows the same result. Michael On 22.09.2017 07:19, Craig Topper wrote: > Is VT a legal type on Hexagon?

Hello Chris, We caught this failure: ./llc -mattr=+avx ../../test/CodeGen/X86/widen_load-2.ll llc: LegalizeTypes.cpp:831: void llvm::DAGTypeLegalizer::SetSplitVector(llvm::SDValue, llvm::SDValue, llvm::SDValue): Assertion `Lo.getValueType().getVectorElementType() == Op.getValueType().getVectorElementType() && 2*Lo.getValueType().getVectorNumElements() ==

Hi Ankur, > The flags "-view-sched-dags".. described in the doc doesn't seem to work. ( > "llc -help" doesn't list it ). as far as I remember, displaying DAGs during compilation is only enabled in "debug builds" [1] of LLVM. You probably have to re-configure and re-compile LLVM to enable this feature. Best regards, Christoph [1]

I am trying to understand the SelectionDAG construction from LLVM IR. I have gone through the doc "The LLVM Target-Independent Code Generator" on LLVM site. This gives a great initial overview. However I am unable to catch the actual control flow for the llvm->selectionDag conversion. The flags "-view-sched-dags".. described in the doc doesn't seem to work. ( "llc

>>>>> I am using GCC 4.3.2 ( Debian 4.3.2-1.1) on x86. I will try out a different compiler. I tried out Sourcery G++ Lite 2009q1-203 (GCC 4.3.3). I still can't get lli to run. This time the error is like this: 0 lli 0x00651128 1 lli 0x00651960 2 libc.so.6 0x40212600 __default_sa_restorer_v1 + 0 3 lli 0x00282ef0 4 lli 0x00283cec

Hi, I'm trying to use llvm/clang to cross compile to sparcv9. The following works with a -march=sparc, but yields errors for sparcv9. Are there some other flags that need to be specified? Thanks, Tarun > clang -m64 -emit-llvm test.c -c -o test.bc > llc -march=sparcv9 test.bc -o hello.s ExpandIntegerResult #0: 0x8a6c478: i64 = GlobalAddress<[4 x i8]* @.str> 0 [ORD=1] [ID=0] Do

I was running into a problem with compiling llvm with gcc 4.4 on fedora 11 with --enable-optimized. I was seeing this warning dozens of times: /net/hakodate/scratch/llvm/llvm/include/llvm/CodeGen/ValueTypes.h: In member function ‘llvm::SDNode*<unnamed>::SPUDAGToDAGISel::Select(llvm::SDValue)’: /net/hakodate/scratch/llvm/llvm/include/llvm/CodeGen/ValueTypes.h:362: warning: comparison always

Hello, After commit r114523, I start to get crash when compiling with clang (Release+Asserts) for i386: (I know I should fill a bug report instead of posting here, but I don't get much time right now). Trying to compile the following simple code, clang asserts. ---------- round.c -------- #include <math.h> float test() { return llround(1); } -------------------- [MacPro:~/Desktop]

Hello everybody, Following on from the excellent help I received at http://comments.gmane.org/gmane.comp.compilers.llvm.devel/52591 - I have a follow up question. I've been editing the SelectionDAGiSel.cpp to try and print out the operations in the nodes, to this end I have modified the SelectionDAGISel::CodeGenAndEmitDAG() function as follows void SelectionDAGISel::CodeGenAndEmitDAG() {

Hi all, I plan to turn on the new type legalization infrastructure "LegalizeTypes" by default tomorrow. This is a redesign/reimplementation of the logic currently in LegalizeDAG that turns (for example) 64 bit arithmetic on a 32 bit machine into a series of 32 bit operations. As well as being a cleaner design, it also supports code generation for arbitrary precision integers such as

On Oct 26, 2008, at 1:03 AM, Duncan Sands wrote: > Hi all, I plan to turn on the new type legalization infrastructure > "LegalizeTypes" by default tomorrow. This is a redesign/ > reimplementation > of the logic currently in LegalizeDAG that turns (for example) 64 bit > arithmetic on a 32 bit machine into a series of 32 bit operations. > As well > as being a