search for: destty

...------------------------------------------------- > ===// > + // Instruction creation methods: Cast/Conversion Operators > + // > = > = > =-------------------------------------------------------------------- > ===// > + > + Value *CreateTrunc(Value *V, const Type *DestTy, const char *Name > = "") { > + return CreateCast(Instruction::Trunc, V, DestTy, Name); > + } > + Value *CreateZExt(Value *V, const Type *DestTy, const char *Name > = "") { > + return CreateCast(Instruction::ZExt, V, DestTy, Name); > + } > +...

Devang Patel wrote: > On Dec 15, 2007, at 12:15 PM, Richard Pennington wrote: > >> I got the current version of LLVM via svn yesterday and modified my >> code to >> use the LLVMFoldingBuilder. Very nice! >> >> My question is this: I noticed that the folding builder doesn't fold >> some >> operations, e.g. casts. Is there some reason why? If

...em to check for address space, it simply >> checks if the integer in question is zero, and folds the inttoptr to null: >> >> >> >> Constant *llvm::ConstantFoldCastInstruction(unsigned opc, Constant *V, >> >> Type *DestTy) { >> >> >> >> ... >> >> >> >> if (V->isNullValue() && !DestTy->isX86_MMXTy()) >> >> return Constant::getNullValue(DestTy); >> >> ... >> >> >> >> >> >> Is this a bug? >...

...lowed by a load using a different type. And I think that doing several scalar operations should give the same result as when using vectors. So bitcast of bitpacked vectors should probably be avoided? This also reminded me of the following test case that is in trunk: test/CodeGen/X86/pr20011.ll %destTy = type { i2, i2 } define void @crash(i64 %x0, i64 %y0, %destTy* nocapture %dest) nounwind { ; X64-LABEL: crash: ; X64: # BB#0: ; X64-NEXT: andl $3, %esi ; X64-NEXT: movb %sil, (%rdx) ; X64-NEXT: andl $3, %edi ; X64-NEXT: movb %dil, (%rdx) ; X64-NEXT: retq %x1 = trunc i64 %x0...

...target has a special instruction to handle it (x86 has pmovmskb for i1 vector bitcasts, but otherwise you probably end up with some terrible lowering involving a lot of shifts). > This also reminded me of the following test case that is in trunk: >  test/CodeGen/X86/pr20011.ll > > %destTy = type { i2, i2 } > > define void @crash(i64 %x0, i64 %y0, %destTy* nocapture %dest) nounwind { > > ; X64-LABEL: crash: > > ; X64:       # BB#0: > > ; X64-NEXT:    andl $3, %esi > > ; X64-NEXT:    movb %sil, (%rdx) > > ; X64-NEXT:    andl $3, %edi > > ; X64...

...536870912 ret i32 %std_ld.i } The contant folder doesn’t seem to check for address space, it simply checks if the integer in question is zero, and folds the inttoptr to null: Constant *llvm::ConstantFoldCastInstruction(unsigned opc, Constant *V, Type *DestTy) { ... if (V->isNullValue() && !DestTy->isX86_MMXTy()) return Constant::getNullValue(DestTy); ... Is this a bug? Thanks Guy From: David Majnemer [mailto:david.majnemer at gmail.com] Sent: Tuesday, June 09, 2015 18:45 To: Benyei, Guy Cc: llvmdev at cs.uiuc.edu Subjec...

They are starting to look complicated. The patch linked is interesting, perhaps v1 vectors are special cased. It shouldn't be too onerous to work out what one or two in tree back ends do by experimentation. Thanks again, it's great to have context beyond the source. On Fri, Sep 15, 2017 at 9:41 PM, Friedman, Eli <efriedma at codeaurora.org> wrote: > On 9/15/2017 12:10 PM, Jon

...mbiner::PropagateAddressSpace(BitCastInst &CI) { + // Determine the new type. This is the old dest type with the address space + // changed. We can't simply use the source type, since the element type can be + // changed in the cast in addition to the address space. + const PointerType *DestTy = cast<PointerType>(CI.getDestTy()); + const PointerType *SrcTy = cast<PointerType>(CI.getSrcTy()); + const PointerType *NTy = PointerType::get(DestTy->getElementType(), SrcTy->getAddressSpace()); + + // Only propagate the address space when the source and dest address spa...

...fficient unless your target has a special instruction to handle it (x86 has pmovmskb for i1 vector bitcasts, but otherwise you probably end up with some terrible lowering involving a lot of shifts). This also reminded me of the following test case that is in trunk: test/CodeGen/X86/pr20011.ll %destTy = type { i2, i2 } define void @crash(i64 %x0, i64 %y0, %destTy* nocapture %dest) nounwind { ; X64-LABEL: crash: ; X64: # BB#0: ; X64-NEXT: andl $3, %esi ; X64-NEXT: movb %sil, (%rdx) ; X64-NEXT: andl $3, %edi ; X64-NEXT: movb %dil, (%rdx) ; X64-NEXT: retq %x1 = trunc i64 %x0...

Hello, It seems that ConstantFoldCastInstruction in ConstantFold.cpp folds inttoptr instruction with 0 as operand to a null pointer. It makes sense, when talking about a C-style frontend, as the C99 spec (6.3.2.3) states: "An integer constant expression with the value 0, or such an expression cast to type void *, is called a null pointer constant." On the other hand, some architectures

...astInst &CI) { > + // Determine the new type. This is the old dest type with the > address space > + // changed. We can't simply use the source type, since the > element type can be > + // changed in the cast in addition to the address space. > + const PointerType *DestTy = cast<PointerType>(CI.getDestTy()); > + const PointerType *SrcTy = cast<PointerType>(CI.getSrcTy()); > + const PointerType *NTy = PointerType::get(DestTy- > >getElementType(), SrcTy->getAddressSpace()); > + > + // Only propagate the address space when the sour...

Hi Eli, Mon Ping, > In ISO/IEC WG14 n1169 on the C extensions to support embedded > processors, any two address spaces must be disjoint, must be > equivalent, or must be nested. Ah, that standard is a lot clearer on this subject than the DSP-C one I read was. > As Eli indicated, the actual relationship is platform specific depending on > what makes the most sense for

In ISO/IEC WG14 n1169 on the C extensions to support embedded processors, any two address spaces must be disjoint, must be equivalent, or must be nested. As Eli indicated, the actual relationship is platform specific depending on what makes the most sense for your hardware and how the program will behave will depend on that relationship. -- Mon Ping On Jul 17, 2008, at 7:25 AM, Eli

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

...rands(LHS, RHS, CC, dl); + LHS = LegalizeOp(LHS); + RHS = LegalizeOp(RHS); LegalizeSetCCCondCode(VT, LHS, RHS, CC, dl); } SDValue ExpandLibCall(RTLIB::Libcall LC, SDNode *Node, bool isSigned, SDValue &Hi); - SDValue ExpandIntToFP(bool isSigned, MVT DestTy, SDValue Source, DebugLoc dl); SDValue EmitStackConvert(SDValue SrcOp, MVT SlotVT, MVT DestVT, DebugLoc dl); SDValue ExpandBUILD_VECTOR(SDNode *Node); @@ -306,12 +165,7 @@ SDValue ExpandBSWAP(SDValue Op, DebugLoc dl); SDValue ExpandBitCount(unsigned Opc, SDValue Op, DebugLoc dl); -...

...t>(Cast0Src) || !isa<ICmpInst>(Cast1Src)) && shouldOptimizeCast(Cast0) && shouldOptimizeCast(Cast1)) { Value *NewOp = Builder->CreateBinOp(LogicOpc, Cast0Src, Cast1Src, I.getName()); return CastInst::Create(CastOpcode, NewOp, DestTy); } ``` The `(!isa<ICmpInst>(Cast0Src) || !isa<ICmpInst>(Cast1Src))` part has been added by r48715 in order to ensure that InstCombine does not enter an endless loop, switching back and forth between the two transformations. There was also added an InstCombine test case `zext-or-icmp.l...

I need to create a cast instruction that casts an sbyte* to another pointer type. Previously I was using the CastInst::createInferredCast() function to do that; however, that function has been removed. Which of the create() functions from CastInst should I use to do that? It seems like the obdvious answer should be createPointerCast(). However, the documentation for createPointerCast

...he generated ConstantExpr C doesn't inherit the inBounds attribute of the original GEP. FYI, the callstack is #0 CastGEPIndices (Ops=..., ResultTy=0x2fb2850, TD=0x2fc8830, TLI=0x2feb390) at ConstantFolding.cpp:623 #1 0x0000000001892dd1 in llvm::ConstantFoldInstOperands (Opcode=29, DestTy=0x2fb2850, Ops=..., TD=0x2fc8830, TLI=0x2feb390) at ConstantFolding.cpp:1040 #2 0x0000000001892647 in ConstantFoldConstantExpressionImpl (CE=0x2fcb0f8, TD=0x2fc8830, TLI=0x2feb390, FoldedOps=...) at ConstantFolding.cpp:931 #3 0x00000000018926d5 in llvm::ConstantFoldConstantExpression...

...isa<ICmpInst>(Cast1Src)) && > shouldOptimizeCast(Cast0) && shouldOptimizeCast(Cast1)) { > Value *NewOp = Builder->CreateBinOp(LogicOpc, Cast0Src, Cast1Src, > I.getName()); > return CastInst::Create(CastOpcode, NewOp, DestTy); > } > ``` > > The `(!isa<ICmpInst>(Cast0Src) || !isa<ICmpInst>(Cast1Src))` part has been added by r48715 in order to ensure that InstCombine does not enter an endless loop, switching back and forth between the two transformations. There was also added an InstCombine test...