The problem is that it shouldn't cover all cases, because effect binary contains specific markers, telling which kind of value assignment that is. E.g 0 - constant, 1 - variable, 2 - constant index array access, etc. This is encoded as effect metadata.
But we could still write a function in fx.c that takes the unmodified block, and identifies the kind of assignment from it, I will try this idea.
Regarding instruction set, it certainly does intersect, but it's not the same. See preshader_ops[] in d3d10/effect.c for known ops. Also there is special way to encode number of used components, and as you can see some instructions do not exist in normal shader language. One option is to have a superset, and then convert them at some point, but to me it seems unfortunate to pollute main compiler logic with marginally used functionality. I don't know what would be the best option.
I don't think we need to add additional instruction opcodes to HLSL IR. The translation to this different set of instructions (the `preshader_ops`) can be contained within fx.c.
We may need though, one or two IR node types, the load of an undefined symbol and maybe the call to an undefined symbol. But that should not interfere with the parsing of other profiles too much.
Also for constant values you can have special predefined constant names like "inv_src_alpha" that are meaningful in context of a state object. We can certainly have all that logic implemented as helpers in fx.c as a number of helpers that would return numeric value for given state object type and constant name.
Okay.