value.cpp: fix some issues

[makigumo]

The old implementation didn't look right, so this is what I assume to be the intended behavior.

[raphaelthegreat]

Comparison of floats is still a bitwise comparison. An IR::Value is a typed union of various values so comparing u16 for both f16 and u16 is perfectly fine. It is technically undefined behavior, because c++ only permits accessing the intended member, but its behavior that is expected to work by basically everyone. So while I agree this is not UB (and better than before), the old implement was still fine. That usage of attribute in Type::U1 looks like a bug tho lol

[makigumo]

As far as I can see there is currently no imm_f16 to do a meaningful compare/hash, that's why I moved the Type::F16 cases down. But I may be wrong.

[raphaelthegreat]

F16 immediates are not used anywhere to my knowledge anyway. F16 type only exists for pack/unpack operations that operate on F16. GCN2 doesn't have proper F16 support seems

[squidbus]

Not sure if we want to move forward with this or not based on comments, although F16 case should probably remain comparing the u16 immediates since there's no native float alternative.

[makigumo]

Restored the previous behavior regarding Type::F16.