Translate phi instructions into generic G_PHI instructions.
This has the same semantic as PHI but has types for operands.
This lets us verify that the G_PHI has compatible types for all operands.
This also allows specifying legalization actions for weird PHI types.
Details
- Reviewers
ab qcolombet t.p.northover dsanders
Diff Detail
Event Timeline
Hi Aditya,
Looks mostly good to me.
Could you add a test case for the "verifier" like diagnostic you've added?
The RegisterBankInfo change seems strange to me. See inline comment.
Cheers,
-Quentin
lib/Target/AArch64/AArch64RegisterBankInfo.cpp | ||
---|---|---|
423–424 | We should need to do that. |
lib/Target/AArch64/AArch64RegisterBankInfo.cpp | ||
---|---|---|
423–424 | When it returns the best mapping, it creates for NumOperands (say with 2 PHI values - it's 5). Then it fails the verification of the best mapping. |
lib/Target/AArch64/AArch64RegisterBankInfo.cpp | ||
---|---|---|
423–424 | Ah right, we want to use the generic getInstrMappingImpl, but now G_PHI falls into the isPreISelGenericOpcode category whereas PHI did not. That being said, all the targets will have the exact same problem therefore, long term, we probably want to have some kind of generic method for this check. Anyhow, that's not really a problem for now and actually we could just skip the check and that would work (as in always calling getInstrMappingImpl and check if the Mapping is valid), though it would a waste of compile time. Anyway, the current change makes sense and I'd expect you'd need to do the same for x86, amdgpu, and arm. | |
test/Verifier/test_g_phi.mir | ||
2 | Could you add a FileCheck to check we issue the expected error? | |
29 | Could you add a comment on what this test is checking? |
We should need to do that.
Could you describe what happen if you don't?