search for: sextload

...D::AssertSext) 2. The MVT::glue value is used to ensure two nodes are scheduled together and in order. In the other word, we can’t insert any instruction of them in the scheduling, is it correct? 3. In the ARMISelLowering constructor, it sets the callback function with setLoadExtAction(ISD::SEXTLOAD, MVT::i1, Promote); My question is ARM don’t support MVT::i1 registerclass, why should it determine this operation with MVT::i1 value? Can anyone tell me? Thank you very much. Best regards, Zakk -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lis...

...is a VALUETYPE node with type MVT::Other that contains the type MVT::i1 as an auxiliary datum. My confusion is the unsupported type( like MVT::i1) have converted > to supported type in LegalizeTypes phase, > They have. but the setXXXXAction > callbacks(like setLoadExtAction(ISD::**SEXTLOAD, MVT::i1, Promote);) > Here MVT::i1 is not referring to the type of any node, it is referring to the extra data held in the VALUETYPE node argument of the SEXTLOAD node. are used to eliminate any operations that are unsupported > on the target in Legalize phase after then LegalizeType pha...

...running after type legalization, the DAG combiner should not introduce any illegal types. When running after operation legalization, the DAG combiner should not introduce any illegal operations. Consider this code from ReduceLoadWidth: if (LegalOperations && !TLI.isLoadExtLegal(ISD::SEXTLOAD, ExtVT)) return SDValue(); Here you see that it checks whether it is only allowed to produce legal operations, and bails out if it would create an illegal extending load. However the later logic in ReduceLoadWidth doesn't do any such checking as far as I can see, which is wrong. Ciao,...

Thanks again for your help Steve, I’m thinking perhaps my “SelectADDRrr” pattern is inadequate. The sign-extension is at the hardware level, the code generator sees (should see) it as a 16-bit signed register value. My implementation is just: bool SHAVEISelDAGtoDAG::SelectADDRrr(SDValue &Addr, SDValue &Base, SDValue &Offset) { if ((Addr.getOpcode() == ISD::ADD) { Base

...ization, the DAG combiner > should not introduce any illegal types. When running after operation > legalization, the DAG combiner should not introduce any illegal operations. > Consider this code from ReduceLoadWidth: > > if (LegalOperations&& !TLI.isLoadExtLegal(ISD::SEXTLOAD, ExtVT)) > return SDValue(); > > Here you see that it checks whether it is only allowed to produce legal > operations, and bails out if it would create an illegal extending load. > However the later logic in ReduceLoadWidth doesn't do any such checking > as far as I ca...

DAGCombiner::ReduceLoadWidth() does the following: /// ReduceLoadWidth - If the result of a wider load is shifted to right of N /// bits and then truncated to a narrower type and where N is a multiple /// of number of bits of the narrower type, transform it to a narrower load /// from address + N / num of bits of new type. If the result is to be /// extended, also fold the extension to form a

On 11 January 2017 at 10:24, Jim Grosbach via llvm-dev <llvm-dev at lists.llvm.org> wrote: > ARM64 is like this. I suggest having a look at that backend (lib/Target/AArch64) and how it deals with implicit zeroing of the upper bits of the X registers. ARM64 has a separate name for the registers as 32-bit values though (W0-W30 rather than X0-X30). I could easily see DAG ISel throwing a fit

Hi,Could someone explain to me how the sign/zero extensions in LLVM work, please? If I understood correctly, the int type in LLVM doesn't keep the information about signedness of an int. So the question is how can I know if instructions like Load or Trunc should be signed or not? I guess that at least ARM backend produces sign extended load so if someone could point me to the code where it

I have an operation which loads a 16 bit block of data as 2 8-bit elements, sign extends the both parts to 32 bits and stores the result into 64-bit vector register. How can I define the pattern for this? just using [(set V2I32Regs:$result, (sextloadv2i8 ADDRrr:$address))] gives me error that extloav2i8 is not defined. (the same principle works for scalar sextload) So I need to define it from the SDNodes? But how? there is no SDNode for extload? it's load with some extra parameters?

...using the triple "aarch64v8.1a-unknown-linux-unknown", and "" for both CPU name and target features string. However when I pass the following target specific features string, I get qemu crashing in the CI: -a35,-a53,-a55,-a57,-a72,-a73,-a75,-a76,-aes,-aggressive-fma,-alternate-sextload-cvt-f32-pattern,+altnzcv,+am,-arith-bcc-fusion,-arith-cbz-fusion,-balance-fp-ops,+bti,-call-saved-x10,-call-saved-x11,-call-saved-x12,-call-saved-x13,-call-saved-x14,-call-saved-x15,-call-saved-x18,-call-saved-x8,-call-saved-x9,+ccdp,+ccidx,+ccpp,+complxnum,+crc,-crypto,-custom-cheap-as-move,-cyclo...

...misinterpreted. Below is what I've tried (on an LLVM last synced with upstream ~3 weeks ago). I've set my target to promote i16 loads in its TargetLowering. setLoadExtAction(ISD::EXTLOAD, MVT::i16, Promote); setLoadExtAction(ISD::ZEXTLOAD, MVT::i16, Promote); setLoadExtAction(ISD::SEXTLOAD, MVT::i16, Promote); The DataLayout is "e-p:32:32:32-i8:8:8-i16:32:32-i32:32:32-n32" If I test with a simple function as the following (which adds two i16 arguments): define zeroext i16 @a(i16 zeroext %x, i16 zeroext %y) nounwind { entry: %x.addr = alloca i16, align 2 %y.addr = al...

On Wed, Feb 18, 2009 at 10:14 AM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > I'm still trying to track down some alignment issues with loads(i.e. 8/16 > bit loads being turned into 32bit sign extending loads) and I cannot for the > life of me seem to figure out how to enter this section of code: > > // If this is an unaligned load and the target doesn't support

..."not yet implemented". Setting it to Expand does not expand it to sign_extend and load but to extload and sign_extend, but I don't support extload either. Please correct me if I am wrong, but I've been looking at this issue for awhile now and I cannot see where it uncombines the sextload to a load and sign_extension. My current solution is to just comment out that combination so that it never occurs. Thanks, Micah

I'm still trying to track down some alignment issues with loads(i.e. 8/16 bit loads being turned into 32bit sign extending loads) and I cannot for the life of me seem to figure out how to enter this section of code: // If this is an unaligned load and the target doesn't support it, // expand it. if (!TLI.allowsUnalignedMemoryAccesses()) { unsigned

On Wed, May 20, 2009 at 4:55 PM, Dan Gohman <gohman at apple.com> wrote: > Can you explain why you chose the approach of using a new pass? > I pictured removing LegalizeDAG's type legalization code would > mostly consist of finding all the places that use TLI.getTypeAction > and just deleting code for handling its Expand and Promote. Are you > anticipating something more

On May 20, 2009, at 1:34 PM, Eli Friedman wrote: > 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

...o = DAG.getExtLoad(ExtType, dl, NVT, Ch, Ptr, SV, - SVOffset, EVT, isVolatile, - Alignment); - - // Remember that we legalized the chain. - AddLegalizedOperand(SDValue(Node, 1), LegalizeOp(Lo.getValue(1))); - - if (ExtType == ISD::SEXTLOAD) { - // The high part is obtained by SRA'ing all but one of the bits of the - // lo part. - unsigned LoSize = Lo.getValueType().getSizeInBits(); - Hi = DAG.getNode(ISD::SRA, dl, NVT, Lo, - DAG.getConstant(LoSize-1, TLI.getShiftAmountTy())); -...