similar to: Inline ASM Question

The reason the ones in PPCInstrInfo.td don't have the patterns to match is the reason they are more analogous to your problem. Namely, tblgen does not have a way to produce nodes with more than one result. The load-with-update instructions do exactly that - one of the inputs is also an output, but the other output is independent (and necessarily a separate register). The FMA variants have

On Tue, 30 May 2017, Nemanja Ivanovic wrote: > This is typically accomplished with something like PPC's `RegConstraint` and > `NoEncode`. You can see examples of it that are very similar to what you're after in > PPC's load/store with update forms (i.e. load a value and update the base register > with the effective address - these are used for pre-increment loads/stores).

I've tried all the types (both for result and Intrinsic ID), can't seem to find what cast is causing the issue here. On Fri, Jun 24, 2016 at 11:47 AM, Ryan Taylor <ryta1203 at gmail.com> wrote: > That's what I thought but I got the same error with: > > DAG.getNode(ISD::INTRINSIC_WO_CHAIN, DL, VT, > DAG.getTargetConstant(Intrinsic::my_intrinsic, DL, MVT::i16), LHS);

Thanks, that sounds like it would work. Was this based on what any other target did? Or do any other targets take this approach? I just want to make sure that we don't already have a hook suitable for this. Overriding runOnFunction to run what could be described as just a "late SelectionDAG pass" sounds pretty intrusive. Do you remember other approaches that didn't work? --

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 intrinsic ID is an int, not a float. —escha > On Jun 24, 2016, at 7:49 AM, Ryan Taylor via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > given the following C code: > > float b=16, a=0; > int main() { > float a = sqrt(b); > return0; > } > > I'm trying to lower FSQRT down, but getting a casting issue, my code is: > > SDValue

On Tue, Oct 11, 2016 at 2:48 PM, Chris Lattner <clattner at apple.com> wrote: > On Oct 11, 2016, at 12:04 AM, Peter Collingbourne <peter at pcc.me.uk> wrote: > > I have been experimenting with a number of approaches to representation in >> SDAG, and I have found one that seems to work best, and would be the least >> intrusive (unfortunately most approaches to this

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

Hello, I am working on a AVR backend and have a version up and running that will convert LLVM IR code to assembly code for my target. I have written a bunch of instructions from the AVR Instruction Set in AVRInstrInfo.td and not much else. In a simple test case I am attempting to compile (if that is the word you are supposed to use for this operation) test.ll: define i8 @foo(i8 %a, i8 %b) {

On Mon, Oct 10, 2016 at 8:31 PM, Chris Lattner <clattner at apple.com> wrote: > > On Oct 10, 2016, at 8:12 PM, Peter Collingbourne via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > Hi all, > > I wanted to summarise some discussion on llvm-commits [0,1] as an RFC, as > I felt it demanded wider circulation. > > Our support for references to absolute

Some time ago I saw a report of strange single-stepping behavior given Swift code that looks like this: 1| var input = [16, 14, 10, 9, 8, 7, 4, 3, 2, 1] //< Only number 1 is relevant. 2| print("start") TL;DR: The debugger steps from line 2 -> 1 -> 2 in this code example. One clean way to fix this bug is to remove debug locations from ConstantSDNodes, and I'm asking if

Hi all, I wanted to summarise some discussion on llvm-commits [0,1] as an RFC, as I felt it demanded wider circulation. Our support for references to absolute symbols is not very good. The symbol will be resolved accurately in non-PIC code, but suboptimally: the symbol reference cannot currently appear as the immediate operand of an instruction, and the code generator cannot make any assumptions

Hello Hal, I have a strong suspicion that your constant folding optimization introduced at r174746 is broken on ARM. There is a bug about it: http://llvm.org/bugs/show_bug.cgi?id=15581 There is no such issue with 3.2, and reverting r174746 on top of r178740 also fixes the problem. I'm trying to fix it myself, but still have no good ideas; so it would be great to have an advice from you.

Is it possible to get a register number to which the value is allocated to in MIPS in DAGToDAG class? More Specifically: SDValue Reg3 = Node->getOperand(3); if (RegisterSDNode *R = dyn_cast<RegisterSDNode>(Reg3)) { op3 = cast<RegisterSDNode>(Reg3)->getReg();

Hi All, I have faced a problem with TargetLowering::SimplifyDemandedBits with AND. Here is a example as following: /* C source code */ struct A { unsigned int a; unsigned char c1, c2; bool b1 : 1; bool b2 : 1; bool b3 : 1; }; int main () { struct A x[1]; x[0].b1 = false; int s = 0; s = x[0].b1 ? 1 : 0; <--- Here is problem. if (s != 0) __builtin_abort

Hello. I come back to this older thread. Again, because of i64immSExt32 I receive TableGen error "Could not infer all types in, pattern!" (exact details written below). So far I'm not able to generate selection code with TableGen for the ADD_r* instructions, etc: def i64immSExt32 : PatLeaf<(imm), [{return

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

I've been debugging some strange happenings over here and I put an assert in APInt to catch what I think is the source of the problem: int64_t getSExtValue() const { // An i1 -1 is unrepresentable. assert(BitWidth != 1 && "Signed i1 value is not representable!"); To me an i1 -1 makes no sense whatsoever. It is not representable in twos-complement form. It cannot

Hi James, Jim If you *really* want this to work in selection DAG then there is a solution, but its not pretty. First make i64 not be legal. Then, assuming the regclass you gave has some subregs, you can give load/store a custom legalisation where you change the i64 to MVT::Untyped. So something like this for ISD::STORE: SDValue ValueToBeStored = St.getOperand(…) auto SeqOps[] = {

> On Feb 27, 2015, at 1:59 AM, Ambuj Agrawal <ambujbwt at gmail.com> wrote: > > Is it possible to get a register number to which the value is allocated to in MIPS in DAGToDAG class? > > More Specifically: > SDValue Reg3 = Node->getOperand(3); > if (RegisterSDNode *R = dyn_cast<RegisterSDNode>(Reg3)) >