Patches for SI

[Michel Dänzer]

On Don, 2013-03-21 at 17:23 +0100, Christian König wrote: 
> Am 21.03.2013 15:02, schrieb Michel Dänzer:
> > On Don, 2013-03-21 at 12:37 +0100, Christian König wrote:
> >> attached are the next bunch of improvements for the SI llvm backend.
> >>
> >> Since Tom is on vacation it's probably on us to review them ourself.
> >> They are stabilizing the register allocation, and so should make it
> >> possible to use RegPressure scheduling again without running out of
> >> registers in (for example) lightsmark.
> > Sounds good.
> >
> > Patch 2 makes sense for the intrinsics loading inputs or constants, but
> > how is texture sampling not reading from memory? :)
> 
> Well also constant loads read from memory, the trick is that this memory 
> isn't supposed to change (Well as long as we don't support image write 
> functions, but AFAIK we don't want to use them with samplers).

Okay.


> > For patch 3, 'switch back to RegPressure' is somewhat misleading, as we
> > were originally not setting any scheduling preference, and I don't think
> > RegPressure is the default? Also, will this tend to result in using more
> > GPRs? Couldn't using fewer GPRs allow dispatching more threads in
> > parallel in some cases?
> 
> No, RegPressure was indeed the default before you changed it to Source. 

Ah, I had previously missed the initialization in AMDIL code.

> The point is that RegPressure should indeed use less GPRs, but that only 
> works if you specify a register pressure, otherwise it seems to just 
> schedule pretty much randomly.

Okay. Looking at the documentation for getRegPressureLimit:

  /// getRegPressureLimit - Return the register pressure "high water mark" for
  /// the specific register class. The scheduler is in high register pressure
  /// mode (for the specific register class) if it goes over the limit.

This sounds to me like it won't try to use fewer registers than the
value returned by this hook, which is all of them with your change?
Though I don't know if that's any worse than returning 0. 

  /// Note: this is the old register pressure model that relies on a manually
  /// specified representative register class per value type.

This sounds like there's a newer (better?) register pressure model.

These issues probably don't block this change, but might be something to
keep in mind for the long run.


-- 
Earthling Michel Dänzer           |                   http://www.amd.com
Libre software enthusiast         |          Debian, X and DRI developer