Instruction MVT::ValueTypes

Is there an easy way to get the MVT::ValueType of a MachineInstruction
MachineOperand? For example, the register operand of an x86 MOVAPD should
have an MVT::ValueType of v2f64. A MOVAPS register operand should have an
MVT::ValueType of v4f32.

So given a MachineInstruction and its MachineOperands is there some easy way
to derive this information? I don't see anything in TargetInstrInfo that
would help.

                                                 -Dave

Is there an easy way to get the MVT::ValueType of a MachineInstruction
MachineOperand? For example, the register operand of an x86 MOVAPD should
have an MVT::ValueType of v2f64. A MOVAPS register operand should have an
MVT::ValueType of v4f32.

The short answer is no. A op of a number of different VTs can map to the same instruction. However, given a register class you can get to the list of VTs that map to it. Take a look at TargetRegisterDesc.

Evan

> Is there an easy way to get the MVT::ValueType of a MachineInstruction
> MachineOperand? For example, the register operand of an x86 MOVAPD
> should
> have an MVT::ValueType of v2f64. A MOVAPS register operand should
> have an
> MVT::ValueType of v4f32.

The short answer is no. A op of a number of different VTs can map to
the same instruction.

In general, that may be true, but for most instructions isn't it 1:1? What
are some examples where it isn't 1:1? The vector processor needs to
know how the data in the register is organized to compute the operation, after
all.

Thinking about MOVAPS / MOVAPD I suppose one could argue that it's
perfectly legal to do a MOVAPD on a vector register that contains 8-bit data.
It's just bits, after all, but there is a "preference" to what should be in
the register for performance reasons. It's not good to mix-and-match MOVAPD
and MOVAPS on the same data.

However, given a register class you can get to
the list of VTs that map to it. Take a look at TargetRegisterDesc.

Tha'ts usually not enough. For example, in an SSE operand you want to know
the type of data contained in it (32-bit [or less] or 64-bit) to generate
optimal code. Just knowing that it's a 128-bit vector register that can hold
8-, 16-, 32- or 64-bit data is not enough.

Getting this information into the TargetInstrInfo / TargetOperandInfo would
take a fair amount of TableGen and .td file hacking, I would think. Right?

                                                        -Dave

For the case of MOVAPS vs. MOVAPD vs. MOVDQU (assuming you have a
micro-architecture where there's actually a difference), this can be
achieved by having instruction selection select the right instructions.
For example, find code like this in X86InstrSSE.td:

def : Pat<(alignedloadv2i64 addr:$src),
           (MOVAPSrm addr:$src)>, Requires<[HasSSE2]>;
def : Pat<(loadv2i64 addr:$src),
           (MOVUPSrm addr:$src)>, Requires<[HasSSE2]>;

and change it to not select MOVAPS for that microarchitecture, for
example.

Dan

Is there an easy way to get the MVT::ValueType of a MachineInstruction
MachineOperand? For example, the register operand of an x86 MOVAPD
should
have an MVT::ValueType of v2f64. A MOVAPS register operand should
have an
MVT::ValueType of v4f32.

The short answer is no. A op of a number of different VTs can map to
the same instruction.

In general, that may be true, but for most instructions isn't it 1:1? What
are some examples where it isn't 1:1? The vector processor needs to
know how the data in the register is organized to compute the operation, after
all.

What about bitcast'ed values? Or i1 value zero-extended and stored in i8 register?

Thinking about MOVAPS / MOVAPD I suppose one could argue that it's
perfectly legal to do a MOVAPD on a vector register that contains 8-bit data.
It's just bits, after all, but there is a "preference" to what should be in
the register for performance reasons. It's not good to mix-and-match MOVAPD
and MOVAPS on the same data.

That's not really true in many cases. On x86, sometimes many opcodes do the same thing. We often use the shortest one. Domain crossing penalty doesn't really matter in newer x86 implementations.

Besides that's just an optimization, it's not an correctness issue.

However, given a register class you can get to
the list of VTs that map to it. Take a look at TargetRegisterDesc.

Tha'ts usually not enough. For example, in an SSE operand you want to know
the type of data contained in it (32-bit [or less] or 64-bit) to generate
optimal code. Just knowing that it's a 128-bit vector register that can hold
8-, 16-, 32- or 64-bit data is not enough.

Another question to ask is... What are you trying to achieve? What crazy ideas do you have?

Evan

Unfortunately that doesn't help when, for example, you need to generate
spill code. :slight_smile:

                                                  -Dave