similar to: [LLVMdev] default operation action

Dear there, I have a target which is supporting the 32 bit operations natively. Right now,I want to make it support the 16 bits operations as well. My initial thought is: (1) I can adding something like “ CCIfType< [i16], CCPromoteToType<i32>>”, to the CallingConv.td, then “all” the 16 bits operands will be automatically promoted to 32 bits, it will be all set. but looks it is not

On Tue, Mar 15, 2016 at 2:21 PM, Krzysztof Parzyszek via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 3/15/2016 4:16 PM, Rail Shafigulin via llvm-dev wrote: > >> Below is the output of llc with a -debug-only=isel. As you could see the >> output type for load, store, and add changes from v4i32 to i32 during >> legalization. How can I preserve the output type to

The PowerPC backend on PPC64 for non-Darwin (SVR4 ABI) systems currently has a problem handling integer types smaller than 64 bits. This is because the ABI specifies that these types are zero-extended to 64 bits on the stack and the default logic provided in LegalizeDAG does not use that convention. Specifically, for these targets we have: setOperationAction(ISD::VAARG, MVT::Other, Expand);

On Fri, 23 Mar 2012 09:50:12 +0100 Ivan Llopard <ivanllopard at gmail.com> wrote: > Hi Finkel, > > Le 23/03/2012 05:50, Hal Finkel a écrit : > > The PowerPC backend on PPC64 for non-Darwin (SVR4 ABI) systems > > currently has a problem handling integer types smaller than 64 bits. > > This is because the ABI specifies that these types are > > zero-extended

Hi Finkel, Le 23/03/2012 05:50, Hal Finkel a écrit : > The PowerPC backend on PPC64 for non-Darwin (SVR4 ABI) systems > currently has a problem handling integer types smaller than 64 bits. > This is because the ABI specifies that these types are zero-extended to > 64 bits on the stack and the default logic provided in LegalizeDAG does > not use that convention. Specifically, for

Le 23/03/2012 17:02, Hal Finkel a écrit : > On Fri, 23 Mar 2012 09:50:12 +0100 > Ivan Llopard<ivanllopard at gmail.com> wrote: > >> Hi Finkel, >> >> Le 23/03/2012 05:50, Hal Finkel a écrit : >>> The PowerPC backend on PPC64 for non-Darwin (SVR4 ABI) systems >>> currently has a problem handling integer types smaller than 64 bits. >>> This

I am trying to lower all llvm operations to 8-bit. So far I was trying to have llvm do all that for me using things like: setOperationAction(ISD::ADD, MVT::ii,Promote); setOperationAction(ISD::ADD, MVT::i8,Legal); setOperationAction(ISD::ADD, MVT::i16,Expand); setOperationAction(ISD::ADD, MVT::i32,Expand); However, I keep getting an assertion failure that operation can not be expanded.

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

On my target store/load of f32 or i32 are equivalents. Previously I had duplicate instructions def in .td to map f32 and i32 to the same opcode. I deleted all that and I instead tried a new approach (to simplify things) : setOperationAction(ISD::STORE, MVT::f32, Promote); AddPromotedToType(ISD::STORE, MVT::f32, MVT::i32); setOperationAction(ISD::LOAD, MVT::f32, Promote);

On Wed, 26 Sep 2007 Alireza.Moshtaghi at microchip.com wrote: > I am trying to lower all llvm operations to 8-bit. So far I was trying > to have llvm do all that for me using things like: ok > setOperationAction(ISD::ADD, MVT::ii,Promote); > setOperationAction(ISD::ADD, MVT::i8,Legal); > setOperationAction(ISD::ADD, MVT::i16,Expand); > setOperationAction(ISD::ADD,

Ahh yep, thanks for catching that, new patch attached. > -----Original Message----- > From: Hal Finkel [mailto:hfinkel at anl.gov] > Sent: Tuesday, July 31, 2012 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

Hi Andrea    Thank you your replying.    I do like your letter. Add following to line to MipsISelLowering.cpp. As your words,   @llvm.convert.to.fp16  can compile successfully. However, the runtime is not right. +  setOperationAction(ISD::FP16_TO_FP32, MVT::f32, Expand);+  setOperationAction(ISD::FP32_TO_FP16, MVT::i32, Expand); Robin yalong at multicorewareinc.com  From: Andrea Di

On Fri, Jan 11, 2013 at 1:08 PM, Andrew Booker <andrew.booker at arm.com>wrote: > The fmuladd intrinsic is described as saying that a multiply and > addition sequence can be fused into an fma instruction "if the code > generator determines that the fused expression would be legal and > efficient". (http://llvm.org/docs/LangRef.html#llvm-fma-intrinsic) > >

Micah, One more thing ;) -- llvm::getEnumName in utils/TableGen/CodeGenTarget.cpp -Hal On Tue, 31 Jul 2012 21:02:02 +0000 "Villmow, Micah" <Micah.Villmow at amd.com> wrote: > Ahh yep, thanks for catching that, new patch attached. > > > -----Original Message----- > > From: Hal Finkel [mailto:hfinkel at anl.gov] > > Sent: Tuesday, July 31, 2012 1:40 PM

Hi Dmitry, > So instead of setOperationAction(ISD::STORE, MVT::i1, Expand); one > should probably do setOperationAction(ISD::STORE, MVT::i1, Custom); > and implement it in NVPTXTargetLowering::LowerOperation. > > But this issue makes a good point about the code efficiency: I suspect > such expansion will be very ugly in terms of performance. Probably we > can do much better if

On Mon, Aug 05, 2013 at 02:09:58PM -0400, Francois Pichet wrote: > On my target store/load of f32 or i32 are equivalents. > Previously I had duplicate instructions def in .td to map f32 and i32 to > the same opcode. > > I deleted all that and I instead tried a new approach (to simplify things) : > > setOperationAction(ISD::STORE, MVT::f32, Promote); >

On Mon, Aug 5, 2013 at 2:25 PM, Tom Stellard <tom at stellard.net> wrote: > On Mon, Aug 05, 2013 at 02:09:58PM -0400, Francois Pichet wrote: > > On my target store/load of f32 or i32 are equivalents. > > Previously I had duplicate instructions def in .td to map f32 and i32 to > > the same opcode. > > > > I deleted all that and I instead tried a new approach

On Thu, Mar 17, 2016 at 2:41 PM, Rail Shafigulin <rail at esenciatech.com> wrote: > On Thu, Mar 17, 2016 at 10:10 AM, Rail Shafigulin <rail at esenciatech.com> > wrote: > >> On Wed, Mar 16, 2016 at 6:38 PM, Mehdi Amini <mehdi.amini at apple.com> >> wrote: >> >>> >>> On Mar 16, 2016, at 5:38 PM, Rail Shafigulin <rail at

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

I think that you attached the wrong patch. The attached patch is the one which adds the new MVT types. From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Villmow, Micah Sent: Saturday, July 28, 2012 01:54 To: Developers Mailing List Subject: [LLVMdev] Vector promotion broken for <2 x [i8|i16]> Vector promotion which is new in LLVM 3.1 is broken for