search for: setoperationactions

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 Guys, I noticed that the operation actions( promote/expand/custom) are set per operation basis. Wondering if we can set it up globally? For example, I have native supported 32 bits registers, to handle 8 bits value operations, I want to do promote. and to support 64 bit operations, I want to expand. If I can set up the operation actions for the same type globally, then I can avoid to

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

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

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

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,

Hi Renato, > * Have some call-back mechanism, possibly upon a flag > (HasSpecialDivRemLowering), and update the remainder result If you setOperationAction on SDIVREM and UDIVREM to Custom you can expand the rtlib call appropriately yourself. There's precedent for sincos on Darwin systems (both ARM and x86) and in AArch64 for basically every operation on fp128. Cheers. Tim.

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

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 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

Folks, I'm working on bug 16387: "clang doesn't produce ARM EABI-compliant modulo runtime function" http://llvm.org/bugs/show_bug.cgi?id=16387 And I need some pointers. I've changed ARMISelLowering::ARMTargetLowering::ARMTargetLowering() to associate __aeabi_idivmod variants to RTLIB::{U,S}DIVREM_* library calls, but now I need to teach the expansion that on AEABI case,

On Fri, Jun 29, 2012 at 2:11 PM, Dmitry N. Mikushin <maemarcus at gmail.com> wrote: > Hi again, > > Kind people on #llvm helped me to utilize bugpoint to reduce the > previously submitted test case. For record, it code be done with the > following command: > > $ bugpoint -llc-safe test.ll > > The resulting IR is attached, and it is crashing in the same way. Is >

Hi everyone, Use setOperationAction to tell system the spectied operation does not work with the specified TYPE. Whoes TYPE is it, result type or operand type? Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20091208/71890cb8/attachment.html>

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