similar to: [LLVMdev] Use of custom operations after DAG legalization

Hello, I'm having trouble getting LLVM to use UMUL_LOHI instead of MUL for unsigned integers. In the TargetLowering constructor I have: setOperationAction(ISD::MUL, MVT::i32, Expand); setOperationAction(ISD::SMUL_LOHI, MVT::i32, Legal); setOperationAction(ISD::UMUL_LOHI, MVT::i32, Legal); The problem seems to be with the code in LegalizeOp() in LegalizeDAG.cpp. Here's a snipet of

I'm trying to implement *MUL_LOHI for my processor. My processor has mulxss (e.g.) that gives the 32 high bits of a 64 bit multiply. I tried this in ios2ISelDAGToDAG.cpp: /// Mul/Div with two results case ISD::SMUL_LOHI: case ISD::UMUL_LOHI: { SDValue Op1 = Node->getOperand(0); SDValue Op2 = Node->getOperand(1); AddToISelQueue(Op1);

Sorry, forgot to Reply-All. Begin forwarded message: > From: Steve Montgomery <stephen.montgomery3 at btinternet.com> > Subject: Re: [LLVMdev] Prevention register promotion at the isel codegen phase > Date: 24 November 2012 17:09:58 GMT > To: Joseph Pusdesris <joe at pusdesris.com> > > I had a similar problem trying to implement reg-mem operations. The solution I

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

Yes, this is very helpful! Thank you! How does this work when exiting a variable's liveness range? Will it automatically know to free the stack slot for reuse? -Joe On Sat, Nov 24, 2012 at 12:23 PM, Steve Montgomery < stephen.montgomery3 at btinternet.com> wrote: > Sorry, forgot to Reply-All. > > Begin forwarded message: > > *From: *Steve Montgomery

Hi Steve, Thanks for the tip regarding MIOperandInfo, I didn't think of that part of the tablegen description. Sadly, I did actually mean: r1 = *(i0 += m0). So increment i0 by m0. Read memory the memory location "pointed" to by i0. Store in r1. Sadly I am not too familiar with compiler terminology, so I don't know if there is a proper term for such a load. On Thu, Oct 23,

Hi Jakob, thanks for the advice. I'll do as you suggest and make sure that CCR is never live. I can use pseudo-instructions to bundle cmp+jump but it's not ideal because I might also have to bundle cmp+jump+jump+... into a pseudo. Also, there are several flavours of cmp instruction so I might need a lot of pseudos. That's what led me to wonder whether MachineInstrBundles might be a

I've got a question about how SelectionDAGBuilder treats loads. The LLVM Language Reference Manual explicitly states that the order of volatile operations may be changed relative to non-volatile operations. However, when the SelectionDAGBuilder in LLVM 3.1 encounters a volatile load, it flushes all pending loads and then chains the volatile load onto them meaning that the volatile load must

I looked into those patches but I don't think they will help in my situation because my problems occur during instruction selection rather than scheduling. A simple and concrete example is a pattern like: [(set GR:$dst (add GR:$src (nvload addr:$mem)))] where nvload matches a load provided that isVolatile() is false. If the selection DAG looks like: | | LD1 LD2 ^

Steve, I had created a patch last year that does something similar to what you describe for regular loads and stores using aliasing information. I think that the last message in the thread was: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20120402/140299.html This approach has worked for me, but it is not the preferred solution going forward. The preferred solution is to keep the

----- Original Message ----- > From: "Bruce Hoult" <bruce at hoult.org> > To: "Johnny Val" <johnnydval at gmail.com> > Cc: "<llvmdev at cs.uiuc.edu>" <llvmdev at cs.uiuc.edu> > Sent: Thursday, October 23, 2014 8:31:35 AM > Subject: Re: [LLVMdev] Question regarding getElementPtr/Addressing modes in backend > > Many CPU

I'm relatively new to LLVM so apologies in advance if this is a dumb question. I've been experimenting with re-targeting LLVM onto a 16-bit micro which has pre and post increment and decrement addressing modes. I've been using llvm-gcc to generate llvm bitcode and llvm 2.7 to go from here to my target assembly code. I've got the Combine pass to deal with

Thanks again for your help Steve, I’m thinking perhaps my “SelectADDRrr” pattern is inadequate. The sign-extension is at the hardware level, the code generator sees (should see) it as a 16-bit signed register value. My implementation is just: bool SHAVEISelDAGtoDAG::SelectADDRrr(SDValue &Addr, SDValue &Base, SDValue &Offset) { if ((Addr.getOpcode() == ISD::ADD) { Base

I forgot to mention that I used EXTRACT_ELEMENT in my backend to get the high and low parts of an SDValue. On 10 Nov 2013, at 17:50, Steve Montgomery <stephen.montgomery3 at btinternet.com> wrote: > I had a similar problem with a backend for the 68HC12 family which also has no barrel shifter. Some 68HC12 CPUs support shift for just one of the 16-bit registers and only support rotation

Thanks Dylan, I am working on a backend which has mulhsu instruction that performs multiplication between signed and unsigned number and returns upper 32 bits into result register. I think I also need to write some code probably as you indicated to check signedness of the operands and based on that lower to mulhsu instruction. -Vivek On Mon, Feb 27, 2017 at 11:13 AM, Dylan McKay <me at

Further to my earlier question, I'm perhaps a bit confused about memory serialisation. The following example, compiled using clang for the MSP430: target datalayout = "e-p:16:16:16-i8:8:8-i16:16:16-i32:16:32-n8:16" target triple = "msp430-??-??" @y = common global i16 0, align 2 @x = common global i16 0, align 2 define void @f() nounwind { entry: %0 = load i16* @y,

>>Note that the isCommutable flag is only really useful for two-address instructions. If the two inputs are not constrained, nothing is really won by swapping them. Ahh i see, good to know that. >> Does the -view-*-dags output look correct? They do look correct, there are three Xmul_lohi blocks, one returns the low part copied into R14 and the rest of combinations get added and merged

Hi, I am writing a backend and having issues with properly lowering the result of getElementPtr ( specifically the add node that it generates). If we take this IR: %struct.rectangle = type { i24, i24 } ; Function Attrs: nounwind readonly define i24 @area(%struct.rectangle* nocapture readonly %r) #0 { entry: %width = getelementptr inbounds %struct.rectangle* %r, i16 0, i32 0 %0 = load i24*

I'm working on an out-of-tree target and am having some problems with rematerialization and spilling. The target's load and store instructions affect the condition code register (CCR). Describing this in the InstrInfo.td file using Defs = [CCR] certainly prevents spills and fills from being inserted where they might clobber CCR but it also prevents the load instruction from being

Hi Christophe, On 05/09/11 18:35, Christophe de Dinechin wrote: > > On 5 sept. 2011, at 17:48, Duncan Sands wrote: > >> since the result of a multiply doesn't depend on the signedness, I find it >> strange that your target differentiates between them. What I'm saying is >> that if you have (say) two i32 numbers a and b and you do a signed multiply: >>