search for: legalizeintegertypes

I'm getting the following error when trying to SDIV integers greater than 128bit (on an AMD64 target). LegalizeIntegerTypes.cpp:2047: void llvm::DAGTypeLegalizer::ExpandIntRes_SDIV(llvm::SDNode*, llvm::SDValue&, llvm::SDValue&): Assertion `LC != RTLIB::UNKNOWN_LIBCALL && "Unsupported SDIV!"' failed. Stack dump: 0. Running pass 'X86 DAG->DAG Instruction Selection' on function...

Hi, In PromoteIntOp_STORE, why can we not promote a value and generate a truncating store if the incoming store is a truncating store? Naively, I can't see why we can promote the incoming value to a legal type and then generate a truncating store. For example, one has incoming code that produces an i16 via some operation and does a truncating store the result of that value in i8.

Hi Mon Ping, > In PromoteIntOp_STORE, why can we not promote a value and generate a > truncating store if the incoming store is a truncating store? as far as I can see you can just remove the assertion. Ciao, Duncan.

...get. I'm using LLVM to decompose the 64-bit integer operations by using 32-bit registers wherever possible and emulating support where not. When looking at the bit shift decomposition I saw what seems to be a bug in the implementation. The affected function is ExpandShiftWithUnknownAmountBit in LegalizeIntegerTypes.cpp. Below is the original code and the proposed fix. Could someone please review the changes? If they are correct how do I go about submitting a patch? Thanks, Javier [Original] /// ExpandShiftWithUnknownAmountBit - Fully general expansion of integer shift /// of any size. bool DAGTypeLegalizer:...

...ly.ll /home/debio/build/vmkit-build/vmkit/lib/Mvm/Runtime/LLVMAssembly64.ll ExpandIntegerResult #0: 0x16fbf88: i64,ch = AtomicCmpSwap 0x16e8d84, 0x16fbf00, 0x16fc3c8, 0x16fc1a8<Volatile LDST8[%ptr]> [ORD=4] [ID=0] Do not know how to expand the result of this operator! UNREACHABLE executed at LegalizeIntegerTypes.cpp:982! Stack dump: 0. Program arguments: /home/debio/build/vmkit-build/vmkit/../llvm//Debug+Asserts/bin/llc -o LLVMAssembly.s 1. Running pass 'Function Pass Manager' on module '<stdin>'. 2. Running pass 'ARM Instruction Selection' on function '@llv...

...eal with that condition. Thanks, Javier -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100824/a66bd3d8/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: LegalizeIntegerTypes.cpp.patch Type: application/octet-stream Size: 3491 bytes Desc: LegalizeIntegerTypes.cpp.patch URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100824/a66bd3d8/attachment.obj>

...LVM to decompose the 64-bit integer operations by using 32-bit registers > wherever possible and emulating support where not. When looking at the bit > shift decomposition I saw what seems to be a bug in the implementation. The > affected function is ExpandShiftWithUnknownAmountBit in > LegalizeIntegerTypes.cpp. Below is the original code and the proposed fix. > Could someone please review the changes? If they are correct how do I go > about submitting a patch? can you please describe the problem and how you fix it (in words, not code). Thanks, Duncan.

...n is splitted > into two (ADD + ADDC / ADDE). These DAG nodes are later matches during > instruction selection. Thanks for all the replies! Taking the hints, here's more datailed flow for the "%1 = add nsw i32 %b, %a" example if someone later will google for it: Source file is LegalizeIntegerTypes.cpp, DAGTypeLegalizer::ExpandIntegerResult(SDNode *N, unsigned ResNo). handles width splitting (which apparently in LLVM slang called "expanding" which I'm, as a novice, find confusing). For add/sub, this calls DAGTypeLegalizer::ExpandIntRes_ADDSUB(SDNode *N, SDValue &Lo, SDValu...

...lect i1 %cmp, i32 1, i32 0 ret i32 %cond } (3) llc -march=sparcv9 test.ll -o test.s ExpandIntegerResult #0: 0xaf38960: i64 = FrameIndex<1> [ORD=2] [ID=0] Do not know how to expand the result of this operator! UNREACHABLE executed at /home/yangyy/git.repo/llvm.git/lib/CodeGen/SelectionDAG/LegalizeIntegerTypes.cpp:1089! 0 llc 0x08c2512b Stack dump: 0. Program arguments: llc -march=sparcv9 test.ll -o test.s 1. Running pass 'Function Pass Manager' on module 'test.ll'. 2. Running pass 'SPARC DAG->DAG Pattern Instruction Selection' on function '@cmp' Aborted (core dumped)...

...n this way, due to the large number of right shifts). Thus, I wish to mark ISD::SHL/SHR as "Custom" in setOperationAction(), but I'm unsure of how to manually split the 32-bit shiftee SDValue into two 16-bit values. The standard logic in /lib/CodeGen/SelectionDAG/LegalizeTypes.cpp and LegalizeIntegerTypes.cpp has a member function called GetExpandedInteger(). Unfortunately, this is a private method, so I can't gain access to this without hacking on code outside of my target's (/lib/Target/x65 in this case). To be 100% clear, I actually already did attempt this route, and when compiling recei...

Hi All, I have some doubt in LLVM Type Legalizer. How will LOAD:i8 with an i16 operand be lowered in type legalizer? (i16 type is not legal for our target) Following assertion in function ExpandIntegerOperand (file LegalizeIntegerTypes.cpp) is not allowing us to change LOAD node. assert(Res.getValueType() == N->getValueType(0) && N->getNumValues() == 1 && "Invalid operand expansion"); LOAD node has two values but the assertion checks N->getNumValues() == 1 which is not letting us change...

...> 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 not know how to expand the result of this operator! UNREACHABLE executed at ~/llvm/lib/CodeGen/SelectionDAG/LegalizeIntegerTypes.cpp:947! 0 libLLVM-2.8svn.so 0xf6f82ef8 1 libLLVM-2.8svn.so 0xf6f82d90 2 0xf776c400 __kernel_sigreturn + 0 3 libc.so.6 0xf5a1cd52 abort + 386 4 libLLVM-2.8svn.so 0xf6f56ee9 5 libLLVM-2.8svn.so 0xf6e43cf2 6 libLLVM-2.8svn.so 0xf6e5206a 7 libLLVM-2.8svn.so 0xf6e5615a...

...LVM to decompose the 64-bit integer operations by using 32-bit registers > wherever possible and emulating support where not. When looking at the bit > shift decomposition I saw what seems to be a bug in the implementation. The > affected function is ExpandShiftWithUnknownAmountBit in > LegalizeIntegerTypes.cpp. Below is the original code and the proposed fix. > Could someone please review the changes? If they are correct how do I go > about submitting a patch? [snip] Please use "svn diff" to generate proposed patches; the form you used is extremely difficult to read. -Eli

...> } > > (3) llc -march=sparcv9 test.ll -o test.s > > ExpandIntegerResult #0: 0xaf38960: i64 = FrameIndex<1> [ORD=2] [ID=0] > > Do not know how to expand the result of this operator! > UNREACHABLE executed at > /home/yangyy/git.repo/llvm.git/lib/CodeGen/SelectionDAG/LegalizeIntegerTypes.cpp:1089! > 0 llc 0x08c2512b > Stack dump: > 0. Program arguments: llc -march=sparcv9 test.ll -o test.s > 1. Running pass 'Function Pass Manager' on module 'test.ll'. > 2. Running pass 'SPARC DAG->DAG Pattern Instruction Selection' on > f...

...n this way, due to the large number of right shifts). Thus, I wish to mark ISD::SHL/SHR as "Custom" in setOperationAction(), but I'm unsure of how to manually split the 32-bit shiftee SDValue into two 16-bit values. The standard logic in /lib/CodeGen/SelectionDAG/LegalizeTypes.cpp and LegalizeIntegerTypes.cpp has a member function called GetExpandedInteger(). Unfortunately, this is a private method, so I can't gain access to this without hacking on code outside of my target's (/lib/Target/x65 in this case). To be 100% clear, I actually already did attempt this route, and when compiling recei...

...455152/Documents/HP/llvm/lib/Support/Unix/Signals.inc:242:0 #3 0x00007fad6b434370 __restore_rt (/lib64/libpthread.so.0+0xf370) #4 0x0000000001ba1734 llvm::DAGTypeLegalizer::PromoteIntOp_ATOMIC_STORE(llvm::AtomicSDNode*) /afs/ inf.ed.ac.uk/user/s14/s1455152/Documents/HP/llvm/lib/CodeGen/SelectionDAG/LegalizeIntegerTypes.cpp:1025:0 Stack dump: 0. Program arguments: /afs/ inf.ed.ac.uk/user/s14/s1455152/Documents/HP/build/bin/clang-6.0 -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -discard-value-names -main-file-name simple.c -mrelocation-model static -mthread-m...

...n this way, due to the large number of right shifts). Thus, I wish to mark ISD::SHL/SHR as "Custom" in setOperationAction(), but I'm unsure of how to manually split the 32-bit shiftee SDValue into two 16-bit values. The standard logic in /lib/CodeGen/SelectionDAG/LegalizeTypes.cpp and LegalizeIntegerTypes.cpp has a member function called GetExpandedInteger(). Unfortunately, this is a private method, so I can't gain access to this without hacking on code outside of my target's (/lib/Target/x65 in this case). To be 100% clear, I actually already did attempt this route, and when compiling recei...

...ean? Are you saying that the type of a pointer is i16, and you are loading an i8 value from the pointed to location? If so, you are in trouble because many parts of the code generator assume that the type of a pointer is legal. > Following assertion in function ExpandIntegerOperand (file > LegalizeIntegerTypes.cpp) is not allowing us to change LOAD node. > > > > assert(Res.getValueType() == N->getValueType(0) && N->getNumValues() == > 1 && "Invalid operand expansion"); > > > > LOAD node has two values but the assertion checks N->getNu...

Hi, When expanding multiply operation in LegalizeTypes LLVM generates some nodes such as UMUL_LOHI (please refer file LegalizeIntegerTypes.cpp - function - ExpandIntegerResult). However while lowering this operation in LegalizeDAG (please refer file LegalizeDAG.cpp - function - LegalizeOp) the comment says "These nodes will only be produced by target-specific lowering.....". LLVM, therefore, does not call the Low...

Hey all, I am trying to implement a subtarget for the X86 architecture that only has 64 bit Registers. While running LLC on the IR for a very simple program, llc fails on an assertion that says it doesn't know how to promote ISD::FRAMEINDEX. I've tried to look for why how to promote the frameindex which is stored in a i32 variable to an i64 variable but can't seem to find where