search for: addliveins

The unchecked assertion that the same register is not added multiple times to the MBB::LiveIn list isn't being respected. Could we add an assertion to check for it? ==== //dwarc/Tools/MetaWare/Toolset/main/dev/llvm/include/llvm/CodeGen/MachineBasicBlock.h#6 - /remote/arctools/marksl/marksl_1/llvm/include/llvm/CodeGen/MachineBasicBlock.h ==== 295,298d294 < /// addLiveIn - Add the

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

Hi, All, I'm trying to build a customized backend and I need to lower the formal arguments like this: There are several specific registers just for storing formal arguments. And also there are several general purpose registers for computation. If there is an instruction which uses parameters, I should first use a move instruction, which moves the value to general purpose register. For

> On Jan 22, 2016, at 1:23 PM, Matthias Braun <mbraun at apple.com> wrote: > >> >> On Jan 22, 2016, at 12:29 PM, Derek Schuff <dschuff at google.com <mailto:dschuff at google.com>> wrote: >> >> Here are 2 patches, which are independent of each other. >> >> The first splits PrologEpilogInserter into 2 parts :

Hi, I define a customized node with customized type. The job of this customized node is to move a value from one register class to another class. I find that if there is no use of the destination register, this node will be deleted from SDAG. For some reasons, I want to keep this node. So I attach mayStore attribute to this node and I hope it will not be deleted. However, it does not work like I

I tried using this flag and it gave me errors on code that otherwise assembles and runs just fine (using the version of Gcra.cpp that Lang wrote). So I'm wondering if I should really be using the flag? I'm using it like this: llc -verify-machineinstrs -load Debug/lib/P4.so -regalloc=gc xxx.bc Susan On 11/15/2012 01:13 PM, Jakob Stoklund Olesen wrote: > > On Nov 15, 2012, at

Hi Susan, Jakob pointed out to me that the Gcra.cpp allocator doesn't record basic-block live-ins, which are used by the verifier to check correctness. You can record which variables are live into a basic block with MachineBasicBlock::addLiveIn(unsigned physReg). I don't know the verifier well, but if it's using other built in infrastructure for register allocation then it may not be

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

...e basic block? Is it true that APSR is never assumed to live across basic block boundaries? Thank you! Ming Zhang >On Aug 2, 2017, at 9:07 AM, Matthias Braun via llvm-dev llvm-dev at lists.llvm.org llvm-dev at lists.llvm.org>> wrote: >Yes LivePhysRegs can do that for you. It has addLiveIns() and addLiveOuts() functions to get the live-in or live-out set for a basic block (make the set is empty when you call these functions). >Yes APSR is marked as a reserved register by the ARM target, this means we do not track liveness for it. >- Matthias >>On Aug 2, 2017, at 2:45 AM...

Hi again, 2009/1/13 Evan Cheng <evan.cheng at apple.com>: > > > On Jan 13, 2009, at 12:27 AM, Roman Levenstein <romix.llvm at googlemail.com> > wrote: > >> 2009/1/13 Evan Cheng <echeng at apple.com>: >>> >>> On Jan 7, 2009, at 2:48 AM, Roman Levenstein wrote: >>> >>>> bb368: 0x8fdad00, LLVM BB @0x8fc2c98, ID#1:

Hi Krzysztof, Thanks for your response. I was trying to map function input parameters to machine specific registers. My solution I found is based to the RegInfo.setSimpleHint() API. Here is the body of the parameters loop of TargetLowering::LowerFormalArguments VReg = RegInfo.createVirtualRegister(RC); RegInfo.setSimpleHint(VReg,CLP::FA_ROFF1+i);

<div class="socmaildefaultfont" dir="ltr" style="font-family:Arial;font-size:10.5pt" ><div dir="ltr" style="font-family:Arial;font-size:10.5pt" ><div dir="ltr" >Matthias,</div> <div dir="ltr" > </div> <div dir="ltr" >Thanks for the response.</div> <div

For my target, I handle incoming memory arguments by creating a store to memory (in LowerCall, [1]), then creating a fixed object on the stack and loading from it (in LowerFormalArguments[2]). This approach was based on MSP430. I now have the problem that the resulting loads in my output assembly are done assuming that the call stack looks something like: ------ MemArg ------ MemArg ------

Hi I find various argument lowering functions that add registers to function live in do the following args_float[ArgNo] = AddLiveIn(MF, args_float[ArgNo], &Alpha::F4RCRegClass); Do these live in registers get used later during liveness analysis/register allocation ? How can I verify if it has indeed impacted the live intervals? thanks shrey

On Nov 15, 2012, at 8:04 PM, Lang Hames <lhames at gmail.com> wrote: > Jakob pointed out to me that the Gcra.cpp allocator doesn't record basic-block live-ins, which are used by the verifier to check correctness. > > You can record which variables are live into a basic block with MachineBasicBlock::addLiveIn(unsigned physReg). I don't know the verifier well, but if

Hi all, Our target does not have native support for 64-bit integers, so we rely on library calls for certain operations (like sdiv). We recently ran into a problem where these operations that are expanded to library calls aren't maintaining the proper ordering in relation to other chains in the DAG. The following snippet of a DAG demonstrates the problem. t0: ch = EntryToken t2:

Here are 2 patches, which are independent of each other. The first splits PrologEpilogInserter into 2 parts : http://reviews.llvm.org/D16481 After looking at the code I thought it made more sense for the major split to include whether callee-saved register spills are supported. So for non-virtual targets, virtual registers are not supported and scavenging is optionally supported, and vice versa

On Jan 13, 2009, at 12:27 AM, Roman Levenstein <romix.llvm at googlemail.com > wrote: > 2009/1/13 Evan Cheng <echeng at apple.com>: >> >> On Jan 7, 2009, at 2:48 AM, Roman Levenstein wrote: >> >>> bb368: 0x8fdad00, LLVM BB @0x8fc2c98, ID#1: >>> Predecessors according to CFG: 0x8fdac90 (#0) >>> %R0<def> = MOVi 0, 14, %reg0,

2009/1/13 Evan Cheng <echeng at apple.com>: > > On Jan 7, 2009, at 2:48 AM, Roman Levenstein wrote: > >> bb368: 0x8fdad00, LLVM BB @0x8fc2c98, ID#1: >> Predecessors according to CFG: 0x8fdac90 (#0) >> %R0<def> = MOVi 0, 14, %reg0, %reg0 >> *** STR %LR<kill>, %R0<kill>, %reg0, 0, 14, %reg0, Mem:ST(4,4) >> [0x8fc2d68 + 0]

So if I create a value with a DAG.getUndef(myVT); call during instruction legalization, how can I access that value as input in another BB/DAG (also during instruction legalization) without worrying about live-ins and/or phi nodes? Can I create a single virtual register and build both a CopyToReg and a CopyFromReg node with it? I assumed that would break SSA. Perhaps I should have said that what