[PPC64] Define sign conditions for each block

[lbianc]

On PPC64 there is more than one Condition Register and depending if the
operation is signed or unsigned, a different CR is set.
After the VASM emission and all optimization phases, the new "Define
Conditions" phase is called to check if the block has signed, unsigned,
neither or both kind of operations, so based on that, the correct
comparing instruction is emitted.

[lbianc]

@mxw this PR has on check pending since I have created it, is there any issue with that?

[aorenste]

@lbianc - weird. The internal tool shows all tests passed. @fredemmott any idea why fb/FB tests is still listed as "In progress"?

[fredemmott]

Bug - we only create/update an 'FB tests' entry if state !== ok

[fredemmott]

Fix ready, ran for just this PR. Problem will still happen on others or if you update this for a while.

[lbianc]

@fredemmott thanks!

[mxw]

Can you check out the comment I left here: #7348 (comment)

I feel like exposing the XLS liveness analysis for SF registers would also be something that you could use here. If you agree, let's hold off on this until I refactor that analysis so that you can use it.

[lbianc]

Yes, seems something that I can use here. No problem wait for that.

One question, with this XLS liveness analysis of SF registers, will I be able to know which instructions use it during the live period?

[lbianc]

Updated to solve conflicts with master.

[hhvm-bot]

@lbianc updated the pull request - view changes - changes since last import

[mxw]

@lbianc—Yes, I'll make it so that you can access the use-instructions.

[mxw]

Okay, I spent some time working on a separate pass for this, but ended up just deciding to use vasm-simplify.cpp. I think that's a better place for this sort of analysis than the emitter, and you can add some flags to Vinstr (there are a few empty bytes) as annotation instead of creating even more ppc64-specific Vinstrs (I think it's best to minimize the number of those where possible).

I would add an extra data structure to the Env in vasm-simplify.cpp, and do an analysis pass that identifies the set of ConditionCodes that each VregSF might be tested with. This can be a conservative analysis, so that you don't have to update the cc-use-set as simplifications are made. Let me know if you think that sounds like it will work for you.

[mxw]

Closing this PR in favor of a potential future implementation of a solution like the one described above.