[LLVMdev] anti-dependency breaking and mask/shift dependencies

Hal Finkel
Mon, 11 Jun 2012 15:07:44 -0000

On Sun, 10 Jun 2012 09:32:45 -0700
Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote:

>
> On Jun 9, 2012, at 10:12 PM, Hal Finkel wrote:
>
> > On PowerPC (at least versions which predate the mfocrf instruction),
> > while there are multiple independent condition registers, the only
> > way to move those registers into a general-purpose register is to
> > use mfcr, which transfers all of the (concatenated) condition
> > registers into one general purpose register, followed by a
> > mask/shift operation to extract the desired pieces.
> >
> > I would like to know if there is any way to model this which is
> > compatible with using anti-dependency breaking on the associated
> > condition-register class. I might be able to define a late-expanded
> > pseudo-instruction which represents both the mfcr and the mask/shift
> > operations, but then those two things would not be independently
> > schedulable.
>
> It's not exactly what you ask for, but you can set the
> hasExtraSrcRegAllocReq flag on the mfcr instruction. That will tell
> the anti-dep breaker to leave that instruction alone while still
> being able to break other anti-dependencies on condition code
> registers.

Interesting; I could set this attribute on a special form of the
comparison instruction, and that would be a work-around for now.

>
> If that is not enough, you will very soon be able to inject a
> target-dependent pass between register allocation and virtual
> register rewriting. You can use the new LiveRegMatrix interface to
> change the virtual register assignments, for example to loosen
> anti-dependencies. I expect to have this ready within the next week.
>

Sounds good; let's talk about this when it is ready.


Also, I think the following might work well: If we add a special kind
of register dependency called a 'remembered' register. This is not a
real dependency meaning that that the instruction does not actually
read or write to the register, but it means that if the register
allocator (or anything else) swaps the referenced register for another
one (or a new virtual register), then the 'remembered' register needs to
be swapped as well. Using this I can create a late-expanded pseuso
which represents the necessary mask/shift operation. This operation has
real read/write dependencies on the GPRs being used, but also needs to
'remember' from which cr the input originally came. On the other
hand, this might create a bunch of dead-register-dependency
special cases in CodeGen which would not be worth the effort. What do
you think?

Thanks again,
Hal

> /jakob
>



--
Hal Finkel
Postdoctoral Appointee
Leadership Computing Facility
Argonne National Laboratory