similar to: [LLVMdev] How to enable use of 64bit load/store for 32bit architecture

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 Apr 2, 2015, at 2:07 PM, Tom Stellard <tom at stellard.net> wrote: > > On Thu, Apr 02, 2015 at 01:35:55PM -0700, Pete Cooper wrote: >> 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

Hi, I'm trying to implement __builtin_setjmp / __builtin_longjmp for Sparc processors. I think I'm very close, but I can't work out how to issue BuildMI-type instructions to load the address of the recovery location (set in setjmp) into a register using the SETHI / OR combination. I can't see any equivalent code anywhere else in Sparc. I imagine this is similar if I try to make a

Dan Gohman wrote: > There certainly are wishlist items for TableGen and TableGen-based > instruction descriptions, though I don't know of an official list. > Offhand, > a few things that come to mind are the ability to handle nodes with > multiple results, Is there an official workaround, BTW? - Volodya

On Jul 1, 2009, at 2:22 PMPDT, Dan Gohman wrote: >> Ops.push_back(DAG.getConstant(1, MVT::i32)); >> Chain = DAG.getNode(ISD::ADD, DAG.getVTList(MVT::Other, MVT::i32), >> &Ops[0], Ops.size()); >> >> Isn't that the way how it is supposed to work? > > ADD does not use a chain, so there's no chain operand, or > MVT::Other result for it in an ADD

I have intrinsic with no return value and I need to match them to machine instructions. If the instruction has a return value I am able to correctly match it, but if I try to create some tablegen code that has no return value, the instruction gets deleted. Here is my profile/node/pattern. Profile: def SDTIL_BinAtomNoRet : SDTypeProfile<0, 3, [ SDTCisPtrTy<0>, SDTCisVT<1, i32>,

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

On Sat, 14 Oct 2006, Roman Levenstein wrote: >> On Sat, 14 Oct 2006, Roman Levenstein wrote: >>> Is it possible to dynamically define implicit defs for some >>> instructions? >> >> Yes! This is what explicit operands are :). Specifically, if you >> want to >> vary on a per-opcode basis what registers are used/def'd by the >> instruction,

Thanks to your help I've actually made some progress... Especially the SelectionDAGNodes.h was a good hint. But there are still some things that I can't figure out: // 'mov eax, 41' Chain = DAG.getCopyToReg(Chain, DAG.getRegister(X86::EAX, MVT::i32), DAG.getConstant(41, MVT::i32), InFlag); InFlag = Chain.getValue(1); // 'inc eax' SDValue eaxVal =

Hi Chris, Thanks for your response. > On Sat, 14 Oct 2006, Roman Levenstein wrote: > > Is it possible to dynamically define implicit defs for some > > instructions? > > Yes! This is what explicit operands are :). Specifically, if you > want to > vary on a per-opcode basis what registers are used/def'd by the > instruction, you can just add those registers

Hi Christian, Ryan just reported to me that llvm-3.4 is no longer building on OS X Leopard (https://trac.macports.org/ticket/41548). It seems the issue is with a commit that you made back in April (referenced below) which added this to SIISelLowering.cpp: // Adjust the writemask in the node std::vector<SDValue> Ops; Ops.push_back(DAG.getTargetConstant(NewDmask, MVT::i32)); for

The code below is triggering some weird behavior that's different from how gcc treats this inline asm. Clang keeps the original type of "loc" as "bool", which generates an "i1 true" after inlining. So far so good. However, during ISEL, the "true" is converted to a signed integer. So when it's evaluated, the result is this: .quad

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

________________________________ From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Chris Lattner Sent: Friday, September 19, 2008 10:49 AM To: LLVM Developers Mailing List Subject: Re: [LLVMdev] Custom Opcodes versus built-in opcodes On Sep 18, 2008, at 4:04 PM, Villmow, Micah wrote: I am using lowering instructions and using custom opcodes that

On Nov 8, 2010, at 10:32 AM, Villmow, Micah wrote: > I have intrinsic with no return value and I need to match them to machine instructions. If the instruction has a return value I am able to correctly match it, but if I try to create some tablegen code that has no return value, the instruction gets deleted. Hi Micah, >From your description it sounds like machine dead code elimination is

On Sep 19, 2008, at 11:35 AM, Villmow, Micah wrote: > Make sure to use DAG.getTargetNode() with custom opcodes. "target" > nodes are encoded with an implicit delta added to their enum value. > > Is this documented anywhere that getTargetNode is the preferred > method to use in a Custom Lowering function? Even the other backends > use getNode in their lowering

Hello. I generated in the back end by hand (in C++ code, not with TableGen) some fancy assembly code using Inline ASM expressions and if I use 2 functions in my source code (but NOT just 1 function; I will not present the functions, but each requires me to generate an Inline ASM expression) I get this error at compilation (at scheduling): BB#0: derived from LLVM BB %entry

Hi, I am working on a LLVM backend that has eight different branch registers. I am having a lot of trouble with implementing the following instructions: addcg $r0.1, $b0.0 = $r0.1, $r0.1, $b0.0 (r is a general purpose register and b is a 1 bit branch register) The branch register is used for carry in and carry out. I have noticed that this instruction is very closely related to the ADDE

I 100% get that we might not like the decisions clang-format is making, but how does one overcome this when adding new code? The pre-merge checks enforce clang-formatting before commit and that's a common review comment anyway for those who didn't join the pre-merge checking group. I'm just wondering are we not all following the same guidelines? Concerns of clang-format not being good

Salut Ivan, On Fri, Jun 1, 2012 at 7:22 AM, Ivan Llopard <ivanllopard at gmail.com> wrote: > Hi Sebastian, > > Le 25/05/2012 18:54, Sebastian Pop a écrit : >> On Thu, May 24, 2012 at 5:40 PM, Sebastian Pop<spop at codeaurora.org>  wrote: >>> On Thu, May 24, 2012 at 5:06 PM, Hal Finkel<hfinkel at anl.gov>  wrote: >>>> Sebastian,