similar to: [LLVMdev] More address registers

Displaying 20 results from an estimated 900 matches similar to: "[LLVMdev] More address registers"

2008 Feb 18
0
[LLVMdev] More address registers
2008/2/15, Andreas Fredriksson <deplinenoise at gmail.com>: > > I tried mocking this up using the following. (Base is what's returned as > the Ax in the move expression above when the DAG is constructed due to > SelectAddr().) > > SDOperand chain = CurDAG->getCopyToReg(Base, M68K::A3, Base); > Base = CurDAG->getCopyFromReg(chain, M68K::A3, MVT::i32);
2009 Apr 13
1
[LLVMdev] Porting LLVM backend is no fun yet
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
2014 Feb 08
2
[LLVMdev] selecting ISD node - help
Hey, I wanted to add an intrinsics to read MSRs. So I added the intrinsics and lowered it to a new ISD node I created ISD::RDMSR, its first operand is the MSR id. I added a case in X86DAGToDAGISel::Select for ISD::RDMSR. Now I know rdmsr works like so: mov r/ecx, <id> rdmsr r/eax holds the lower 32/64 bit >From what I understood this needs a Token Factor node, nodes which are
2009 Jul 01
3
[LLVMdev] Inserting nodes into SelectionDAG (X86)
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
2010 Sep 09
0
[LLVMdev] Possible missed optimization? 2.0
On Sep 9, 2010, at 12:59 PM, Borja Ferrer wrote: > Hello, i've noticed a new possible missed optimization while testing more trivial code. > This time it's not a with a xor but with a multiplication instruction and the example is little bit more involved. > > C code: > > typedef short t; > t foo(t a, t b) > { > t a4 = a*b; > return a4; > } >
2017 Dec 24
4
Canonical way to handle zero registers?
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? --
2015 Mar 09
2
[LLVMdev] LLVM Backend DAGToDAGISel INTRINSIC
I am currently working on DAGToDAGISel class for MIPS and am trying to figure out a way to use INTRINSIC_W_CHAIN for an intrinsic which can return a value. My intrinsic is defined as: Intrinsic<[llvm_i32_ty],[llvm_i32_ty,llvm_i32_ty,llvm_i32_ty,llvm_i32_ty],[IntrReadWriteArgMem]>; i.e. it has four arguments and one return value In DAGToDAGISel when I try to pass it with four arguments and
2009 Jul 03
0
[LLVMdev] Inserting nodes into SelectionDAG (X86)
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 =
2011 Jul 05
2
[LLVMdev] load/store in IR without stack/heap
Hi all, Can anyone give an idea to solve my problem? I'm implementing backend part using LLVM for my research architecture. The main issue is that this architecture cannot use stack/heap. So, all the value should be stored in the register. Given that architecture, load/store instruction in IR uses virtual register to load/ store the value. For example: C source code is: if(...) { a = 1;
2014 Feb 08
2
[LLVMdev] selecting ISD node - help
Hi Tim, Tim Northover-2 wrote > The code used for DIV is around X86ISelDAGToDAG.cpp:2415, but from a > glance the key points seem to be: > 1. use the second result of getCopyToReg (i.e. SDValue(setIdNode, 1)) > in the RDMSR node. > 2. Give your RDMSR node type MVT::Glue instead of MVT::Other I tried doing what you said, and the DAG looks like how I think it supposed to look like
2010 Sep 09
2
[LLVMdev] Possible missed optimization? 2.0
Hello, i've noticed a new possible missed optimization while testing more trivial code. This time it's not a with a xor but with a multiplication instruction and the example is little bit more involved. C code: typedef short t; t foo(t a, t b) { t a4 = a*b; return a4; } argument "a" is passed in R15:R14, argument "b" in R13:R12, the return value is stored in
2008 Feb 23
1
[LLVMdev] Obligatory monthly tail call patch
Hello everybody, hi Evan, this patch changes the lowering of arguments for tail call optimized calls. Before arguments that could be overwritten by each other were explicitly lowered to a stack slot, not giving the register allocator a chance to optimize. Now a sequence of copyto/copyfrom virtual registers ensures that arguments are loaded in (virtual) registers before they are lowered to the
2014 Oct 21
2
[LLVMdev] Question regarding getElementPtr/Addressing modes in backend
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*
2012 Dec 03
1
[LLVMdev] operator overloading fails while debugging with gdb for i386
On 3 December 2012 10:42, Mayur Pandey <mayurthebond at gmail.com> wrote: > So this seems to be the cause of the problem. I guess you're mixing two different problems. First, is the possible lack of conformance with the ABI you state, which I can't comment since I don't know that ABI very well. Second, is the fact that clang is not printing correct debug information (or is
2008 Sep 23
2
[LLVMdev] Store patterns accepting i32 only?
I'm trying to write a store pattern that accepts both i32 and f32, however, when tablegen generates the code, it only generates the code for i32 only. def ADDR : ComplexPattern<i32, 2, "SelectADDR", [], []>; def MEM : Operand<i32> { let PrintMethod = "printMemOperand"; let MIOperandInfo = (ops GPR, GPR); } def global_st :
2014 Oct 23
2
[LLVMdev] Question regarding getElementPtr/Addressing modes in backend
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,
2009 Jul 13
0
[LLVMdev] [PATCH] Support asm comment output
On Jul 13, 2009, at 10:02 AM, David Greene wrote: >>> - Tag instructons with source line information (customers really >>> want this). >> >> Right, that would be nice. This should be synthesizable from the >> DebugLoc on the instruction in the asm printer, no need to >> redundantly >> encode it into the comment field. > > Except the DebugLoc
2008 Sep 23
0
[LLVMdev] Store patterns accepting i32 only?
On Sep 23, 2008, at 10:44 AM, Villmow, Micah wrote: > I’m trying to write a store pattern that accepts both i32 and f32, > however, when tablegen generates the code, it only generates the > code for i32 only. > > def ADDR : ComplexPattern<i32, 2, "SelectADDR", [], []>; > def MEM : Operand<i32> { > let PrintMethod = "printMemOperand";
2014 Oct 23
2
[LLVMdev] Question regarding getElementPtr/Addressing modes in backend
----- 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
2016 Jun 04
4
Gluing arbitrary nodes together
Hello all, I am working on adding atomics support to the AVR backend. Because the target can only have one core, it is sufficient to: - Save the status register - Disable interrupts - Do the nonatomic LOAD/STORE/SWAP/ADD - Restore the status register I’d really like to be able to do this at the IR level. What I want to do is write a custom lowering hook to convert ISD::ATOMIC_LOAD