search for: ppcf128

...if (Value.getOpcode() != ISD::TargetConstantFP) { SDValue Tmp; switch (CFP->getValueType(0).getSimpleVT().SimpleTy) { default: llvm_unreachable("Unknown FP type"); case MVT::f80: // We don't do this for these yet. case MVT::f128: case MVT::ppcf128: break; case MVT::f32: if ((isTypeLegal(MVT::i32) && !LegalOperations && !ST->isVolatile()) || TLI.isOperationLegalOrCustom(ISD::STORE, MVT::i32)) { Tmp = DAG.getConstant((uint32_t)CFP->getValueAPF(). bi...

...======================= > --- lib/Target/PowerPC/PPCISelLowering.cpp (revision 54985) > +++ lib/Target/PowerPC/PPCISelLowering.cpp (working copy) > @@ -78,9 +78,6 @@ > // from FP_ROUND: that rounds to nearest, this rounds to zero. > setOperationAction(ISD::FP_ROUND_INREG, MVT::ppcf128, Custom); > > - // PowerPC has no intrinsics for these particular operations > - setOperationAction(ISD::MEMBARRIER, MVT::Other, Expand); > - > // PowerPC has no SREM/UREM instructions > setOperationAction(ISD::SREM, MVT::i32, Expand); > setOperationAction(ISD::URE...

Hi All, I am looking at a linker error under O2: undefined symbol __lshrdi3 I have two questions here: 1. Does that mean our libgcc (?) doesn't implement __lshrdi3? Or more generally, why I have such linker error? 2. Seems some operations are combined, and replaced with __lshrdi3 call. I am interested in when such libcall will be generated? Could you show me one

...================================================ --- lib/Target/PowerPC/PPCISelLowering.cpp (revision 54985) +++ lib/Target/PowerPC/PPCISelLowering.cpp (working copy) @@ -78,9 +78,6 @@ // from FP_ROUND: that rounds to nearest, this rounds to zero. setOperationAction(ISD::FP_ROUND_INREG, MVT::ppcf128, Custom); - // PowerPC has no intrinsics for these particular operations - setOperationAction(ISD::MEMBARRIER, MVT::Other, Expand); - // PowerPC has no SREM/UREM instructions setOperationAction(ISD::SREM, MVT::i32, Expand); setOperationAction(ISD::UREM, MVT::i32, Expand); -------------...

...================================================ --- lib/Target/PowerPC/PPCISelLowering.cpp (revision 54985) +++ lib/Target/PowerPC/PPCISelLowering.cpp (working copy) @@ -78,9 +78,6 @@ // from FP_ROUND: that rounds to nearest, this rounds to zero. setOperationAction(ISD::FP_ROUND_INREG, MVT::ppcf128, Custom); - // PowerPC has no intrinsics for these particular operations - setOperationAction(ISD::MEMBARRIER, MVT::Other, Expand); - // PowerPC has no SREM/UREM instructions setOperationAction(ISD::SREM, MVT::i32, Expand); setOperationAction(ISD::UREM, MVT::i32, Expand); Index: lib/Ta...

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

...nd(0)); switch (TLI.getOperationAction(Node->getOpcode(), Node->getValueType(0))){ @@ -4152,51 +3494,7 @@ } break; } - break; - case Expand: { - MVT VT = Op.getValueType(); - MVT OVT = Node->getOperand(0).getValueType(); - // Convert ppcf128 to i32 - if (OVT == MVT::ppcf128 && VT == MVT::i32) { - if (Node->getOpcode() == ISD::FP_TO_SINT) { - Result = DAG.getNode(ISD::FP_ROUND_INREG, dl, MVT::ppcf128, - Node->getOperand(0), DAG.getValueType(MVT::f64)); - Result =...

...strcpy, strncpy, strlen, strpbrk, strtol, strtod, strtof, strtoul, strtoll, strtold, strtoull, strtold, strtoull, strspn, strcspn, strstr, memcmp, memcpy, memmove, memset, __strcpy_chk, cosf, cos, cosl, powf, pow, powl, llvm.pow.f32, llvm.pow.f64, llvm.pow.f80, llvm.pow.f128, llvm.pow.ppcf128, exp21, exp2, exp2f, llvm.exp2.ppcf128, llvm.exp2.f128, llvm.exp2.f80, llvm.exp2.f64, llvm.exp2.f32, floor, cell, round, rint, nearbyint, ffs, ffsl, ffsll, abs, labs, llabs, isdigit, isascii, toascii, sprintf, print, fwrite, fputs, fprintf, puts. Test cases that exercise the library call...

On Thu, May 27, 2010 at 7:09 PM, John Criswell <criswell at uiuc.edu> wrote: > I believe what you want is documented here: > > http://llvm.org/docs/LangRef.html#datalayout > Just a note, since it might be a bug on the backend or documentation. It says on the documentation that size for f is either 32 or 64, however, sparc has 64 and 128. -- PMatos

On Thu, May 27, 2010 at 11:18 AM, Paulo J. Matos <pocmatos at gmail.com> wrote: > On Thu, May 27, 2010 at 7:09 PM, John Criswell <criswell at uiuc.edu> wrote: >> I believe what you want is documented here: >> >> http://llvm.org/docs/LangRef.html#datalayout >> > > Just a note, since it might be a bug on the backend or documentation. > It says on the

...===== >> --- lib/Target/PowerPC/PPCISelLowering.cpp (revision 54985) >> +++ lib/Target/PowerPC/PPCISelLowering.cpp (working copy) >> @@ -78,9 +78,6 @@ >> // from FP_ROUND: that rounds to nearest, this rounds to zero. >> setOperationAction(ISD::FP_ROUND_INREG, MVT::ppcf128, Custom); >> >> - // PowerPC has no intrinsics for these particular operations >> - setOperationAction(ISD::MEMBARRIER, MVT::Other, Expand); >> - >> // PowerPC has no SREM/UREM instructions >> setOperationAction(ISD::SREM, MVT::i32, Expand); >> setO...

On Aug 19, 2008, at 7:18 AMPDT, Gary Benson wrote: > Hi all, > > I'm trying to implement llvm.memory.barrier on PowerPC. I've modelled > my patch (attached) on the implementation in X86, but when I try and > compile my test file (also attached) with llc I get the error "Cannot > yet select: 0x10fa4ad0: ch = MemBarrier 0x10fa4828, 0x10fa4c68, > 0x10fa4be0,

This looks OK to check in, do you have write access? On Aug 21, 2008, at 6:38 AMPDT, Gary Benson wrote: > Dale Johannesen wrote: >> On Aug 19, 2008, at 7:18 AMPDT, Gary Benson wrote: >>> I'm trying to implement llvm.memory.barrier on PowerPC. I've >>> modelled my patch (attached) on the implementation in X86, but >>> when I try and compile my test

> -----Original Message----- > From: Hal Finkel [mailto:hfinkel at anl.gov] > Sent: Tuesday, December 01, 2015 1:01 AM > To: Tim Shen > Cc: Gao, Yunzhong; llvm-dev at lists.llvm.org; Kit Barton; Nemanja Ivanovic > Subject: Re: [llvm-dev] Endianness for multi-word types > > ----- Original Message ----- > > From: "Tim Shen via llvm-dev" <llvm-dev at

...VM : : CodeGen/PowerPC/iabs.ll LLVM : : CodeGen/PowerPC/indirectbr.ll LLVM : : CodeGen/PowerPC/int-fp-conv-0.ll LLVM : : CodeGen/PowerPC/int-fp-conv-1.ll LLVM : : CodeGen/PowerPC/lsr-postinc-pos.ll LLVM : : CodeGen/PowerPC/ppc32-vaarg.ll LLVM : : CodeGen/PowerPC/ppcf128-4.ll LLVM : : CodeGen/PowerPC/rlwimi-keep-rsh.ll LLVM : : CodeGen/PowerPC/rlwimi3.ll LLVM : : CodeGen/PowerPC/select-cc.ll LLVM : : CodeGen/PowerPC/shift128.ll LLVM : : CodeGen/PowerPC/stack-protector.ll LLVM : : CodeGen/PowerPC/tailcall1-64.ll LLVM : : Cod...

I don’t think bfloat should be handled this way. What Amara is suggesting is an optimization, i.e., if we drop the information we are still correct. With bfloat, if we do an operation on float16 instead of bfloat16 this is a correctness problem. So that means that either we need to have new opcodes for bfloat or we need to carry around the floating point type in MIR. I think it would be more