Thanks for the guidance. I hope you don’t mind that I’m adding LLVMDev to this e-mail thread, as it seems as though it may be of general interest.
I agree that duplicating the FP opcodes should be our goal. I just wasn’t sure that was entirely possible. I’ll try adding implicit defs in the way you’ve suggested, but I’m concerned that there may be code that relies on the TII for that kind of thing – for instance, InstrEmitter::EmitMachineNode() does this:
bool HasPhysRegOuts = NumResults > NumDefs && II.getImplicitDefs()!=nullptr;
where “NumDefs” comes from TII and “NumResults” comes from the node. Obviously we can fix that up as needed, but it seems like a weak point in the design. Perhaps it is still better than trying to maintain a duplicate set of opcodes though.
I’m still trying to piece together how to get the set of nodes to be updated from the SelectionDAG to the InstrEmitter. I’m still learning my way around this code.
In any event, I can confirm that for X86 targets the control register uses are not currently modeled. I just committed a patch yesterday adding the MXCSR register and updating the instructions that directly read and write it (but still implicitly so). I suppose you are correct that there is no reason not to add uses of that register to the instructions that derive their rounding behavior from it and then the constrained FP intrinsics will just need to add implicit defs where needed. I’ll also need to add the x87 control register as that isn’t modeled at all right now.