[llvm] r188362 - Replace EVT with MVT in isVectorShift. Keeps compiler from generating unneeded checks and handling for extended types.

[Craig Topper]

I believe every legal type for all supported targets needs to be
represented in the enum inside of MVT. EVT is a wrapper around an MVT and a
Type*. If the type is one of the MVT types the Type* is null and the MVT
defines the define. Otherwise the MVT is INVALID_SIMPLE_VALUE_TYPE and the
Type* points to a Type object that can represent an arbitrary type.

SDNodes always use the EVT object to represent their types. But after types
have been legalized all those EVTs should have an MVT value and null Type*.

All of the places I converted from EVT to MVT were in operation
legalization which occurs after type legalization. So everything should be
an MVT at that point.

During instruction selection SDNodes get turned into MachineSDNodes which
still contain EVTs(which are really just MVTs). Then MachineSDNodes are
converted to MachineInstructions. I believe that's the point when EVTs go
away.



On Wed, Aug 14, 2013 at 4:13 PM, Sean Silva <silvas at purdue.edu> wrote:

> Hi Craig, do you know if we have any documentation regarding what MVT and
> EVT are and how they fit in with the rest of the backend process? The
> documentation for the respective classes in ValueTypes.h sheds some light
> on the situation (MVT represents machine types, and EVT is a superset
> including non-legal types), but it's not clear for example at what stage in
> the codegen process they are formed and during which parts of the codegen
> process they are relevant (e.g., they don't appear to be present at the MI
> level (grepping MachineFunction.h and MachineInstr.h doesn't find
> anything), so when do they go away?).
>
> -- Sean Silva
>



-- 
~Craig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130814/67cae859/attachment.html>