There seems to be quite a few places where the EVT type is used, but the code asserts if the variable/parameter is assigned something else than an MVT. Are there any general objections to replace EVT with MVT in these cases?
For example, a quick look at TargetLowering.h give me this list of (member) functions, taking an EVT parameter, that asserts if the argument is not an MVT:
getRegClassFor, getRepRegClassFor, getRepRegClassCostFor, setTypeAction, getLoadExtAction, isLoadExtLegal, getTruncStoreAction, isTruncStoreLegal, getIndexedLoadAction, getIndexedStoreAction, getCondCodeAction, getTypeToPromoteTo, addRegisterClass
Please do. MVT is cheaper than EVT and conceptually cleaner when dealing with physical machine types. EVT should only be used in parts of the code generator that are "pre-legalization" because they can represent arbitrary IR types. Anything that takes a legal machine type should take an MVT.
A side issue of this is that it is currently relatively hard to add new machine-specific register types. The only way of doing this involves extending MVT, which requires tweaking three files in the (nominally) target-independent parts of the compiler. It would be great if we could simply reserve a (small?) number of MVTs for target-specific legal values.
I added MVT::Untyped a while back to address this kind of use case. You can construct node of MVT::Untyped, and as long as the InstrEmitter can infer what register class they can map to from their uses, everything should just work. Of course, it's only been seriously tested with register sequence (REG_SEQUENCE) nodes.
Thanks. Does this work with, for example, values that must be of a pointer type in the selection DAG? That's currently the issue that I'm hitting: I have a few ugly hacks to disable that test on some intrinsic nodes, but I don't want to have to disable it on all of them.