search for: gettypeforevt

...1:40 PM > To: Villmow, Micah > Cc: Developers Mailing List > Subject: Re: [LLVMdev] Vector promotion broken for <2 x [i8|i16]> > > Micah, > > I think that your patch is missing the necessary modifications in > lib/VMCore/ValueTypes.cpp to EVT::getEVTString() and EVT::getTypeForEVT. > > -Hal > > On Fri, 27 Jul 2012 22:54:24 +0000 > "Villmow, Micah" <Micah.Villmow at amd.com> wrote: > > > Vector promotion which is new in LLVM 3.1 is broken for sub32 bit > > types. The problem is in the VectorLegalizer::PromoteVectorOp. The >...

...Developers Mailing List > > Subject: Re: [LLVMdev] Vector promotion broken for <2 x [i8|i16]> > > > > Micah, > > > > I think that your patch is missing the necessary modifications in > > lib/VMCore/ValueTypes.cpp to EVT::getEVTString() and > > EVT::getTypeForEVT. > > > > -Hal > > > > On Fri, 27 Jul 2012 22:54:24 +0000 > > "Villmow, Micah" <Micah.Villmow at amd.com> wrote: > > > > > Vector promotion which is new in LLVM 3.1 is broken for sub32 bit > > > types. The problem is in the Ve...

Micah, I think that your patch is missing the necessary modifications in lib/VMCore/ValueTypes.cpp to EVT::getEVTString() and EVT::getTypeForEVT. -Hal On Fri, 27 Jul 2012 22:54:24 +0000 "Villmow, Micah" <Micah.Villmow at amd.com> wrote: > Vector promotion which is new in LLVM 3.1 is broken for sub32 bit > types. The problem is in the VectorLegalizer::PromoteVectorOp. The > function getTypeToPromoteTo will return...

Hi Dale, I think Bob is right: the type legalizer shouldn't be turning v16i8 into v16i32, what should happen is that the return type of the BUILD_VECTOR continues to be v16i8, but the type of the operands changes to i32, so you end up with a BUILD_VECTOR that takes 16 lots of i32, and produces a v16i8. The target then has all the info it needs to produce the best code, but needs to be careful

Vector promotion which is new in LLVM 3.1 is broken for sub32 bit types. The problem is in the VectorLegalizer::PromoteVectorOp. The function getTypeToPromoteTo will return a <2 x i32> for a <2 x i8>, <2 x i16> or <4 x i8>. The problem is that there are no vectors of size 1 defined for i32 or i16. The attached patch fixes these issues. This can be reproduced by setting in

...rand(2); // nested function > @@ -1399,16 +1406,13 @@ SDValue PPCTargetLowering::LowerTRAMPOLINE(SDValue Op, > > // Lower to a call to __trampoline_setup(Trmp, TrampSize, FPtr, ctx_reg) > std::pair<SDValue, SDValue> CallResult = > - LowerCallTo(Chain, Op.getValueType().getTypeForEVT(*DAG.getContext()), > + LowerCallTo(Chain, Type::getVoidTy(*DAG.getContext()), I don't see why you are changing the return type here. It is the return type of "__trampoline_setup" (whatever that is) and that didn't change. > false, false, false, false,...

Hi! Attached set of patches splits llvm.init.trampoline into an "init" phase and an "adjust" phase, as discussed on the "Go on dragonegg" thread. Thanks! -- Sanjoy Das http://playingwithpointers.com -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Split-intrinsics-and-DAG-nodes.patch Type: text/x-diff Size: 8808 bytes Desc: