[llvm-commits] [llvm] r157006 - in /llvm/trunk/lib/CodeGen: MachineScheduler.cpp RegisterPressure.cpp RegisterPressure.h

Sergei Larin slarin at codeaurora.org
Wed Aug 15 11:56:42 PDT 2012


Andy,

 

  I am still at an earlier stage.   I am trying to "port" VLIW scheduler to
the "new" MI infrastructure. So far I simply copied default implementation
and trying to make it work as is for my back end.

I currently have no reg pressure interface, so as a result the scheduler
basically picks "NCAND" every time. I am trying to define these methods to
enable reg pressure tracking:

 

// Get the weight in units of pressure for this register class.

  virtual const RegClassWeight &getRegClassWeight(

    const TargetRegisterClass *RC) const = 0;

 

  /// Get the number of dimensions of register pressure.

  virtual unsigned getNumRegPressureSets() const = 0;

 

  /// Get the name of this register unit pressure set.

  virtual const char *getRegPressureSetName(unsigned Idx) const = 0;

 

  /// Get the register unit pressure limit for this dimension.

  /// This limit must be adjusted dynamically for reserved registers.

  virtual unsigned getRegPressureSetLimit(unsigned Idx) const = 0;

 

  /// Get the dimensions of register pressure impacted by this register
class.

  /// Returns a -1 terminated array of pressure set IDs.

  virtual const int *getRegClassPressureSets(

    const TargetRegisterClass *RC) const = 0;

 

.but kind of uncertain about intent around getRegClassPressureSets - I am
trying to read the code in RegisterPressure.cpp, but it sure would be much
easier if I would know your intent. 

 

Here is what I gather so far, please tell me if I am wrong:

getRegClassWeight - should reflect how "expensive" a specific RC is.

getRegPressureSetLimit - is when I start to worry about register pressure
(threshold of a sort).

getNumRegPressureSets - total number of sets(?)

getRegPressureSetName - their name. 

 

But I am not sure what getRegClassPressureSets should produce.

 

One set per RC? Is it multiple sets per RC? If so, what is the heuristic for
split? Calle/caller save etc?

 

Anything else I am missing for full reg pressure tracking?

 

 

Thanks for the help. 

 

Sergei

 

 

--

Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum.

 

From: Andrew Trick [mailto:atrick at apple.com] 
Sent: Wednesday, August 15, 2012 12:36 PM
To: Sergei Larin
Cc: llvm-commits at cs.uiuc.edu
Subject: Re: [llvm-commits] [llvm] r157006 - in /llvm/trunk/lib/CodeGen:
MachineScheduler.cpp RegisterPressure.cpp RegisterPressure.h

 

 

On Aug 15, 2012, at 10:07 AM, Sergei Larin <slarin at codeaurora.org> wrote:


 Are there any examples/documentation on implementing the reg pressure
hooks for a back end?

 

Sergei,

 

The MachineScheduler currently implements register pressure "back-off". It
simply prioritizes instructions that don't increase pressure beyond some
limit. I can think of a few more sophisticated ways to control pressure but
haven't determined yet if they're worth implementing.

 

Even though back-off is a simple mechanism, the policy can become
complicated by how the pressure limit is determined. The current
(experimental) policy is implemented in MachineScheduler.cpp
compareRPDelta(). The pressure tracker will give you a pressure "delta"
between it's current position and some given instruction to-be-scheduled.
The delta has three components. You can probably just choose one that makes
the most sense for you.

 

You may also decide whether you care about all "pressure sets" derived from
your target description, or you can pick a particular register class that
interests you and find the maximal pressure set affected by that class.

 

The best documentation we have so far are the comments in
RegisterPressure.h.  I expect this design to change considerably as we tune
performance. I can give you more detailed answers once you have specific
questions.

 

-Andy 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120815/ed0bb035/attachment.html>


More information about the llvm-commits mailing list