[llvm] [X86][GlobalIsel] Reland G_ISFPCLASS (PR #165848)

[via llvm-commits]

mahesh-attarde wrote:

> You should not be touching the instruction select pass. This is purely an x86 selector bug

I agree, This is terrible way to approach it and needs approach you mentioned if no general use. Patch however intends address same.

For Selection DAG, we have done this in `InstrEmitter::EmitSubregNode`.
https://github.com/mahesh-attarde/llvm-project/blob/jf_fplass_spr/llvm/lib/CodeGen/SelectionDAG/InstrEmitter.cpp#L517 which has generic InstrEmitter.  This was unexpected lengthy debug since we dont expect opts in emitter.

My intent is discussion trade-off for following.
1. If there is general use, should we define GISEL opcode for "G_EXTRACT_SUBREG"  ?
    It seems overengineering just for X86 (or RISCV AFAIK), It seems like too trivial case to miss. So it is left out intentionally?
    Does it need broad discussion?
2. Add post-isel fixup pass/hook to address similar adjustment ?
   Apart from Iteration, I dont see any issue if fixup lands just after `instruction-select`. 
   This seems like narrow and easy approach.

What do you think?
@e-kud @arsenm 

https://github.com/llvm/llvm-project/pull/165848