similar to: Invalid number for the given node in SelectionDAG

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.

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,

> -----Original Message----- > From: Jim Grosbach [mailto:grosbach at apple.com] > Sent: Monday, November 08, 2010 10:41 AM > To: Villmow, Micah > Cc: LLVM Developers Mailing List > Subject: Re: [LLVMdev] Creating tablegen patterns for intrinsics with > no return value. > > > On Nov 8, 2010, at 10:32 AM, Villmow, Micah wrote: > > > I have intrinsic with no

Hi, During instruction selection, I have the following code for certain LOAD instructions: const LoadSDNode *LD = cast<LoadSDNode>(N); SDNode* LDW = CurDAG->getMachineNode(AVR::LDWRdPtr, SDLoc(N), VT, PtrVT, MVT::Other, LD->getBasePtr(), LD->getChain()); // Honestly, I have no idea what this does, but other memory // accessing instructions

OK, the code for sdivrem in APInt.h is wrong. Here's what's written: static void sdivrem(const APInt &LHS, const APInt &RHS, APInt &Quotient, APInt &Remainder) { if (LHS.isNegative()) { if (RHS.isNegative()) APInt::udivrem(-LHS, -RHS, Quotient, Remainder); else APInt::udivrem(-LHS, RHS, Quotient, Remainder); Quotient =

I wrote the following bit of code static APInt FloorOfQuotient(APInt a, APInt b) { unsigned bits = a.getBitWidth(); APInt q(bits, 1), r(bits, 1); APInt::sdivrem(a, b, q, r); * errs() << "sdivrem(" << a << ", " << b << ") = (" << q << ", " << r << ")\n"; * if (r == 0) return q; else {

"Caldarale, Charles R" <Chuck.Caldarale at unisys.com> wrote: > > APInt q(bits, 1), r(bits, 1); > > The APInt constructor has three arguments, the last one being whether or not the value is to be treated as signed. > It defaults to false, as you appear to have just verified. The initial values of q and r shouldn't make a difference (note that several of the

add object rules so that the division, remainder and friends get really build on sparc, patch from Fabio M. Di Nitto <fabbione@ubuntu.com>. reworked to apply on latest git tree. Signed-off-by: maximilian attems <maks@sternwelten.at> --- Has been since long in the Debian and Ubuntu klibc. diff --git a/klibc/arch/sparc/Makefile.inc b/klibc/arch/sparc/Makefile.inc index

On 7/29/2017 1:28 AM, Dr. ERDI Gergo via llvm-dev wrote: > Hi, > > During instruction selection, I have the following code for certain > LOAD instructions: > > const LoadSDNode *LD = cast<LoadSDNode>(N); > SDNode* LDW = CurDAG->getMachineNode(AVR::LDWRdPtr, SDLoc(N), > VT, PtrVT, MVT::Other, > LD->getBasePtr(), LD->getChain()); >

Hi, I'm not sure. But in your lowered DAG the chain nodes are the first operands for you custom nodes, however for the other nodes the chain is the last operand. I seem to remember that during targetlowering the chain is the first operand and then it seems to switch over after ISelDAG, this confused me and may have something to do with the issue that you are seeing. I really don't

Hi Tom, Matt, I'm working on a project that needs few coherent atomic operations (HSA mode: load, store, compare-and-swap) for std::atomic_uint in HCC. the attached patch implements atomic compare and swap for SI+ (untested). I tried to stay within what was available, but there are few issues that I was unsure how to address: 1.) it currently uses v2i32 for both input and output. This

Hi, Pondering the code for StrongSIV and trying to write my own, I find I have many questions. In this code, for example, * if (isa<SCEVConstant>(delta) && isa<SCEVConstant>(srcCoeff)) { const SCEVConstant *constDelta = cast<SCEVConstant>(delta); const SCEVConstant *constCoeff = cast<SCEVConstant>(srcCoeff); APInt distance, remainder;

This problem was reported to me by a friend who has an LLVM port that is not put back to open source. Essentially, there is an intrinsic call _lr which is a load register. so then user code has something like: start_time = _lr(TIMER_REGISTER) ..... some_code_to_time .... end_time = _lr(TIMER_REGISTER) So what happens is that LLVM moves the code as follows: start_time = _lr(TIMER_REGISTER)

On Tuesday 24 February 2009 22:19:27 Arnold Schwaighofer wrote: > What i was trying to say is that if you have > > i32 a() { > %1 = tailcall b() > ret %1 > } > > > i32 b() { > %1 = tailcall c() > ret %1 > } > > i32 c() { > %1 = tailcall d() > ret %1 > } > > i32 d() { > ret i32 5 > } > > only d() will actually

Right now the MemSDNode keeps a volatile bit in the SubclassData to mark volatile memory operations. We have some changes we'd like to push back that adds a NonTemporal flag to MemSDNode to mark instructions where movnt (on x86) and other goodness can happen (we'll also add the TableGen patterns to properly select movnt). In our tree we simply added another flag to the MemSDNode

Hey, I’ve been working on custom lowering ISD::UMUL_LOHI and ISD::SMUL_LOHI. Our target has some legal vector types but no support for these so would like to mark them as Expand. This yields “Cannot unroll a vector with multiple results!” from the default case in VectorLegalizer::Expand. Hence custom lowering. All the types are legal at this stage. I would appreciate some clarification on

0, i32 %1) >> >> Note that if you have a series of sequential recursive tail calls this >> move will only performed once (at the bottom of the recursion, >> respectively when the recursion returns) so it's impact on performance >> should be minimal. > > Hmm, that makes it sound as though the moves between a tail call and the > following return are

Hello all, I would like to propose a large change to LLVM that I would be happy to implement. The instruction selection legalizer knows of three different ways to legalize an action (ignoring an already legal action). - Expansion - Promotion - Custom Expanding a node will lead to one of two things - the operation will be split into several equivalent smaller operations (i.e. 64-bit

On 2015/8/4 3:44, Alexei Starovoitov wrote: [SNIP] >> I'll post 2 LLVM patches by replying this mail. Please have a look and >> help me >> send them to LLVM if you think my code is correct. > > [SNIP] > patch 2: > do we really need to hack clang? > Can you just define a function that aliases to intrinsic, > like we do for ld_abs/ld_ind ? > void

Hello, After commit r114523, I start to get crash when compiling with clang (Release+Asserts) for i386: (I know I should fill a bug report instead of posting here, but I don't get much time right now). Trying to compile the following simple code, clang asserts. ---------- round.c -------- #include <math.h> float test() { return llround(1); } -------------------- [MacPro:~/Desktop]