PR1350 (Vreg subregs) questions

What's the best way to get an SDNode through to DAG scheduling without getting mangled during Lowering/ISel?

When should subregs be flattened to actual registers: AsmPrinter? Somewhere in LiveIntervals, during RegAlloc?

Is there are common API used to turn vregs into physregs that could be changed to flatten any subregs in a central location?

What's the best way to get an SDNode through to DAG scheduling
without getting mangled during Lowering/ISel?

What do you mean by "mangled"? Please clarify.

When should subregs be flattened to actual registers: AsmPrinter?
Somewhere in LiveIntervals, during RegAlloc?

You mean turning part of a larger physical register into a sub-register? I would think LiveIntervals or else copy coalescing might not work right.

Evan

What’s the best way to get an SDNode through to DAG scheduling
without getting mangled during Lowering/ISel?

What do you mean by “mangled”? Please clarify.

My mangled I mean the nodes shouldn’t be isel’ed into anything else because they need to survive through to scheduling. Is there a preferred means of having those nodes skipped during selection and lowering?

When should subregs be flattened to actual registers: AsmPrinter?
Somewhere in LiveIntervals, during RegAlloc?

You mean turning part of a larger physical register into a sub-
register?

Yes.

I would think LiveIntervals or else copy coalescing might
not work right.

Ok. Can you give me some hints as to starting points in LiveIntervals?

> What's the best way to get an SDNode through to DAG scheduling
> without getting mangled during Lowering/ISel?

What do you mean by "mangled"? Please clarify.

My mangled I mean the nodes shouldn't be isel'ed into anything else because they need to survive through to scheduling. Is there a preferred means of having those nodes skipped during selection and lowering?

You'll have to teach legalize and isel about these nodes, just like they know about ISD::Register nodes. subregs will be a new first-class node type that all of the dag stuff will have to know about (at least to pass them through).

> When should subregs be flattened to actual registers: AsmPrinter?
> Somewhere in LiveIntervals, during RegAlloc?

This should definitely be done during regalloc.

-Chris

What’s the best way to get an SDNode through to DAG scheduling
without getting mangled during Lowering/ISel?

What do you mean by “mangled”? Please clarify.

My mangled I mean the nodes shouldn’t be isel’ed into anything else because
they need to survive through to scheduling. Is there a preferred means of
having those nodes skipped during selection and lowering?

You’ll have to teach legalize and isel about these nodes, just like they
know about ISD::Register nodes. subregs will be a new first-class node
type that all of the dag stuff will have to know about (at least to pass
them through).

Great! Found the spot to do that.

When should subregs be flattened to actual registers: AsmPrinter?
Somewhere in LiveIntervals, during RegAlloc?

This should definitely be done during regalloc.

It seems that LiveIntervals will need to be taught about the new form of virtual registers. Hrm. I’m going to try to break this work up as much as possible.

Also, do you see any problems with using the following class for vregs? It makes it possible to not have to go through and update every call site for a large number of functions.

class vreg : public std::pair<unsigned,unsigned> {
public:
vreg(unsigned f) : std::pair<unsigned,unsigned>(f, 0) {}
};

If this definition is OK, where should it live? It’s needed all over the place…

> > > When should subregs be flattened to actual registers: AsmPrinter?
> > > Somewhere in LiveIntervals, during RegAlloc?

This should definitely be done during regalloc.

It seems that LiveIntervals will need to be taught about the new form of virtual registers. Hrm. I'm going to try to break this work up as much as possible.

Splitting up the work is good :slight_smile:

Also, do you see any problems with using the following class for vregs? It makes it possible to not have to go through and update every call site for a large number of functions.

class vreg : public std::pair<unsigned,unsigned> {
public:
vreg(unsigned f) : std::pair<unsigned,unsigned>(f, 0) {}
};

If this definition is OK, where should it live? It's needed all over the place...

Where would you use this? It seems that the only place that would need it is in the DAG schedulers, which turn the dags into a machineinstr stream. If so, putting it into the scheduler baseclass would make sense.

If you do something like this, I'd suggest a trivial value class that doesn't derive from std::pair.

-Chris

When should subregs be flattened to actual registers: AsmPrinter?
Somewhere in LiveIntervals, during RegAlloc?

This should definitely be done during regalloc.

It seems that LiveIntervals will need to be taught about the new form of
virtual registers. Hrm. I’m going to try to break this work up as much as
possible.

Splitting up the work is good :slight_smile:

Also, do you see any problems with using the following class for vregs? It
makes it possible to not have to go through and update every call site for a
large number of functions.

class vreg : public std::pair<unsigned,unsigned> {
public:
vreg(unsigned f) : std::pair<unsigned,unsigned>(f, 0) {}
};

If this definition is OK, where should it live? It’s needed all over the
place…

Where would you use this? It seems that the only place that would need it
is in the DAG schedulers, which turn the dags into a machineinstr stream.
If so, putting it into the scheduler baseclass would make sense.

It gets used in MachineInstrBuilder, MachineInstr, MRegisterInfo, and ScheduleDAG. Basically any place where a vreg currently gets passed around by an unsigned needs to accept the pair. In my working copy I’ve split it out into it’s own header file to reduce extraneous includes.

If you do something like this, I’d suggest a trivial value class that
doesn’t derive from std::pair.

By a value class do you mean a subclass of Value or just a class with no superclass?

Where would you use this? It seems that the only place that would need it
is in the DAG schedulers, which turn the dags into a machineinstr stream.
If so, putting it into the scheduler baseclass would make sense.

It gets used in MachineInstrBuilder, MachineInstr, MRegisterInfo, and ScheduleDAG. Basically any place where a vreg currently gets passed around by an unsigned needs to accept the pair. In my working copy I've split it out into it's own header file to reduce extraneous includes.

Ok, I suggest putting it in MachineInstr.h then.

If you do something like this, I'd suggest a trivial value class that
doesn't derive from std::pair.

By a value class do you mean a subclass of Value or just a class with no superclass?

Just a class with no superclass :slight_smile:

-Chris