similar to: Selection DAG chain question

Re: Do they really need to be chained with each other or anything else Yes. For 2 reasons. Our architecture lowers udivmem into something with 1 producer and 2 consumers. Reason 1) neither the producers nor the consumers must get reordered. Reason 2) one of the consumers might be missing (either the div or mod consumer might not be present. Yet we need to keep the consuming instruction with side

I did it by code preparing into an intrinsic that has side effects. Pseudo instruction would work as well. I'm not sure if glue would help, since the nodes A->B, C->D from example above are not necessarily adjacent. More hooks into the selection DAG builder may be an idea for a LLVM extension. For example in this case, custom allowing for a node to be built with an existing chain would

> Chain doesn't guarantee that operations on parallel chains don't get interleaved This would be a sequential chain... > This is the case for all operations expanded as library calls I think their originating node already has a chain (i.e. mem operand or side effect in llvm-ir). My case is a arithmetic node without ordering constraints (divrem) getting lowered into sth that _does_

> No, non-sideeffecting operations can be legalized as compiler-rt calls Right, but not as "regular" nodes with side-effects? I guess you could search and analyze the DAG manually but that seems hacky. Maybe something that one day LLVM could support natively. On Thu, Jul 16, 2020 at 11:55 AM Matt Arsenault <arsenm2 at gmail.com> wrote: > > > On Jul 16, 2020, at

Yea. I think AMD chains the node they're expanding into, but they don't chain it into an _existing_ chain. e.g. adding A->B to the DAG is ok. But adding A->B and next C->D with B->C is the problem. I appreciate the input On Thu, Jul 16, 2020 at 2:04 PM Matt Arsenault <arsenm2 at gmail.com> wrote: > > > > On Jul 16, 2020, at 17:00, Hendrik Greving

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 =

newbee here. What's the difference between glue and chain? Why can't we add chains to any node we want? On Fri, Jul 17, 2020, 10:25 PM Björn Pettersson A via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Still sounds to me as Glue might help (as already proposed by Craig), but > maybe I’ve misunderstood something. > > > > Another option is to do a simple

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.

A constant i1 is stored as a one bit APInt wrapped in a ConstantInt which is then wrapped in ConstantSDNode for SelectionDAG. The BUILD_VECTOR will just point to the same ConstantSDNode for each element. There is no concept of a sign in the storage. It's just a bit. Whether or not its treated as 1 or negative 1 is going to depend on the code looking at the value including printing code. And

The vnot PatFrag uses ImmAllOnesV which should put an OPC_CheckImmAllOnesV in the matcher table. And the matcher table should call ISD::isBuildVectorAllOnes. I believe we use vnot with vXi1 vectors on X86 and I haven't seen any issues. The FIXME you pointed to seems related to a scalar patcher not a vector pattern. In that case the issue is that the immediate matcher for scalars calls

Hi LLVM, This is my idea I had some time ago, when I realized that LLVM did not support legalization of some arithmetic instructions like mul i256. I have implemented very simple and limited version of that in my project. Is it something LLVM users would appreciate? 1. The pass transforms IR and is meant to be run before CodeGen (after IR optimizations). 2. The pass replaces

I’m hitting TableGen errors trying to match the smullohi <lhs> <rhs> node in TableGen. smullohi returns two results, which is the problem. I am not sure how to match against multiple results. The only other nodes to return two operands are umullohi, udivrem, and sdivrem. There are no examples of these in TableGen in tree. The closest I can get is this: set (R1, R0, (umullohi

Hello, It looks like that in the DAG matcher, the DAG has a xor with '-1' for checking a true value vector for instance, %cmp4.i = icmp ne <8 x i32> %6, %5 %7 = xor <8 x i1> %cmp4.i, <i1 true, i1 true, i1 true, i1 true, i1 true, i1 true, i1 true, i1 true> [use of %7] results in vector of '-1' in the DAG. This also seems the reason why LLVM's vnot PatFrag

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 {

I am having trouble adding a node to the selection DAG (e.g. during combine) E.g. node1 -> use1, use2 Now if you add a node2, with node1 -> node2 with node2 number of output values equal node1 number of output values, then combine as well as e.g. promotion pass with replace all of node1's uses with node2, leaving node1 dead. While this is kind of expected, does this mean a) always

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,

Skipping the clang question for now, this had to be a loop pragma of some kind. One step back: what we really need is a way to express that memory accesses between iterations can be re-ordered. The code that's being compiled _is_ noalias, but we don't _have_ to use noalias semantics, e.g. loop parallel semantics are sufficient. What's missing is a way to express that past the llvm

Would you guys be open to supporting a new hint with the right semantics, like e.g. llvm.loop.noalias_accesses?! I would need to find support in clang however and the main point of support would be the loop unroller behaving as stated in the OP. On Thu, May 14, 2020 at 3:04 PM Michael Kruse <llvmdev at meinersbur.de> wrote: > Trivial example: > > #pragma clang loop

Ok, thanks. Except the question was meant slightly different. Less w.r.t. organizing the register classes, and more w.r.t. implementation. I've noticed for instance that when trying to model this straight forwardly by writing a vreg from spills and reading this from fills (not further elaborated here), that the spiller can't handle vreg def-use pairs: there are assertions making sure a

This is interesting! So are you saying that loop.parallel_accesses strictly loop parallel, and says nothing about aliasing? I see, I guess we may have been "abusing" the hint and re-purposed it. But isn't llvm's vectorizer using loop.parallel_accesses to vectorize loops including vectorize memory accesses that if you ignore loop-carried dependencies, usually means effectively