search for: targetregisterinfo

Dear, I have been going through the Targets registered with llvm. As I was looking around, I found an include statement in the file XXXRegisterInfo.h (XXX is any target), #include "llvm/Target/TargetRegisterInfo.h" The question is there is no folder called Target in my llvm directory (file TargetRegistorInfo.h missing ) and still programs compile in the XXX architecture. I want access to TargetRegisterInfo.h. Can someone point me in the right direction? -- Pratik -------------- next part ----------...

To fix some problems with how condition registers are saved/restored for PowerPC, I need to override TargetRegisterInfo::hasReservedSpillSlot() in PPCRegisterInfo. I've had some difficulties because of the constness of the function, and I'm wondering what the best way to handle this would be. Essentially I need to add a field to PPCRegisterInfo, and modify that field in hasReservedSpillSlot. (I need to re...

Hi, Would anyone object to my moving the TargetRegisterInfo and TargetInstrInfo classes into libCodeGen? TargetInstrInfo is already halfway there with its TargetInstrInfoImpl class implementing most shared functionality. The lib/Target/TargetInstrInfo.cpp file has two remaining functions that happen to not depend on libCodeGen, but I don't think they s...

...c -O3 on x86, -O2 on ARM). I'm going to revert it for now until it has been addressed. > > Probably caused by this member: > > /// KillIndices - The index of the most recent kill (proceding bottom-up), > /// or ~0u if the register is not live. > unsigned KillIndices[TargetRegisterInfo::FirstVirtualRegister]; > > And this: > > std::fill(KillIndices, array_endof(KillIndices), ~0u); > > It should probably be dynamically allocated with TRI->getNumRegs() members instead. Yep. David Goodwin is going to fix it. Evan > > /jakob >

On Nov 27, 2012, at 10:24 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > Would anyone object to my moving the TargetRegisterInfo and TargetInstrInfo classes into libCodeGen? > > TargetInstrInfo is already halfway there with its TargetInstrInfoImpl class implementing most shared functionality. The lib/Target/TargetInstrInfo.cpp file has two remaining functions that happen to not depend on libCodeGen, but I don't th...

...o be undone after the performance regression it introduced was fixed. Can someone please revert it back (i.e. increase the max physreg size to 16K or even better to 32K) to enable us to experiment with large register number machines again? :) It was this trivial patch: Index: include/llvm/Target/TargetRegisterInfo.h =================================================================== --- include/llvm/Target/TargetRegisterInfo.h (revision 89468) +++ include/llvm/Target/TargetRegisterInfo.h (working copy) @@ -299,8 +299,8 @@ /// FirstVirtualRegister - This is the first register number that is...

On Nov 27, 2012, at 11:23 AM, Chris Lattner <clattner at apple.com> wrote: > On Nov 27, 2012, at 10:24 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: >> Would anyone object to my moving the TargetRegisterInfo and TargetInstrInfo classes into libCodeGen? >> >> TargetInstrInfo is already halfway there with its TargetInstrInfoImpl class implementing most shared functionality. The lib/Target/TargetInstrInfo.cpp file has two remaining functions that happen to not depend on libCodeGen, but I don&...

Would it be possible to increase TargetRegisterInfo::FirstVirtualRegister to something quite a bit larger - such as 2^31? I'm working on a target where all SSA values need to be assigned physical registers, and the current limit of 16384 may limit the size of programs that I'm able to handle. 2^31 is a nice value since there are equal numb...

Hi all, I ran into this while trying to figure out why the X86 getSUBriOpcode/getADDriOpcode functions are duplicated, appearing once in X86RegisterInfo.cpp and once in X86FrameLowering.cpp, The method TargetRegisterInfo::eliminateCallFramePseudoInstr doesn't appear to really belong in this interface. It adds instructions into the MachineFunction given to it, which isn't what TargetRegisterInfo is supposed to do. ISTM that eliminateCallFramePseudoInstr belongs in TargerFrameLowering, since it's being u...

...t 2:36 PM, Tim Northover <t.p.northover at gmail.com> wrote: > Hi Pratik, > > > The question is there is no folder called Target in my llvm directory > (file > > TargetRegistorInfo.h missing ) and still programs compile in the XXX > > architecture. I want access to TargetRegisterInfo.h. > > Can someone point me in the right direction? > > Includes are mostly relative to "include/". In this case > "include/llvm/Target/TargetRegisterInfo.h". > > Cheers. > > Tim. > -- Pratik -------------- next part -------------- An HTML attac...

...Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > > On Nov 27, 2012, at 11:23 AM, Chris Lattner <clattner at apple.com> wrote: > >> On Nov 27, 2012, at 10:24 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: >>> Would anyone object to my moving the TargetRegisterInfo and TargetInstrInfo classes into libCodeGen? >>> >>> TargetInstrInfo is already halfway there with its TargetInstrInfoImpl class implementing most shared functionality. The lib/Target/TargetInstrInfo.cpp file has two remaining functions that happen to not depend on libCodeGen, bu...

..., t32 ... Instruction Selection correct : i32 = ADDrr i32, i32 *** MachineFunction at end of ISel *** # Machine code for function _Z11scalar_loopPsS_ss: IsSSA, TracksLiveness ... %31:sfgpr32 = ADDrr killed %32:sgpr32, %27:sgpr32 ... Here should not select f32 sfgpr32 register, debugger point to TargetRegisterInfo:: getCommonSubClass(const TargetRegisterClass *A, const TargetRegisterClass *B, const MVT::SimpleValueType SVT = MVT::SimpleValueType::Any) This function has been called 10+ in LLVM, only one place give specific SVT parameter. Most of thos...

Hi everyone, I'm looking through codes related to registered pressure tracking, mainly the source files 'RegisterPressure.h/cpp', 'MachineRegisterInfo.h/cpp', 'TargetRegisterInfo.h/cpp'. There is a concept I can hardly understand, the 'register pressure set'. Class 'TargetRegisterInfo' defines two virtual methods 'getRegClassPressureSets' and 'getRegUnitPressureSets' for querying but I don't see any subclasses overriding it. What&...

Hi Anton, Anton Korobeynikov wrote: > I don't see any huge problems with writing such pass: just create > stack frame objects at fixed offsets inside your MF pass - and you'll > done. The only problem is that you need to do this early - before > prologue / epilogue inserter code runs, since afterwards stack frame > layout is almostly finalized (at "high level")

Hi, Nicolas > Could you point me where those hooks are in the llvm code? I didn't find > any. Look into PrologEpilogInserter.cpp::PEI::runOnMachineFunction(). There are calls to hooks inside TargetRegisterInfo: TargetRegisterInfo::processFunctionBeforeCalleeSavedScan() and TargetRegisterInfo::processFunctionBeforeFrameFinalized(). Maybe they are not so convenient when working via JIT but at least you'll know the place, where all stack-related stuff is being cooked :) -- With best regards, Anton Ko...

On Jan 6, 2011, at 10:11 PM, andrew at sidefx.com wrote: > Would it be possible to increase TargetRegisterInfo::FirstVirtualRegister > to something quite a bit larger - such as 2^31? I'm working on a target > where all SSA values need to be assigned physical registers, and the > current limit of 16384 may limit the size of programs that I'm able to > handle. 2^31 is a nice value since...

On May 17, 2011, at 2:10 PM, Justin Holewinski wrote: > I plan on eventually implementing both and seeing which works best for different types of input. > > If virtual registers are used, how do you disable final register allocation in the back-end? If post-RA passes have trouble with virtual registers, you probably need to implement your own addCommonCodeGenPasses() method.

...that included in the necessary locations is all that is needed so it doesn't bloat the code. Micah From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Justin Holewinski Sent: Monday, May 16, 2011 6:52 AM To: LLVM Developers Mailing List Subject: [LLVMdev] TargetRegisterInfo and "infinite" register files Currently, the TableGen register info files for all of the back-ends define concrete registers and divide them into logical register classes. I would like to get some input from the LLVM experts around here on how best to map this model to an architecture t...

/// emitProlog/emitEpilog - These methods insert prolog and epilog code into /// the function. The return value is the number of instructions /// added to (negative if removed from) the basic block (entry for prologue). /// virtual void emitPrologue(MachineFunction &MF) const = 0; virtual void emitEpilogue(MachineFunction &MF, MachineBasicBlock

On Jan 6, 2011, at 10:39 PM, andrew at sidefx.com wrote: > >> If you're interested in doing this, I'd suggest hacking up the backend to >> not run register allocation, and represent all your "physical" registers >> are virtual registers. This gives you an unlimited number. >> > > Yes it would be ideal to use all virtual registers, but a