Going from LDX to LD requires that the LDX be word aligned in the first place. This is a requirement of the LD instruction bot not of the LDX instruction. If we are not word aligned we must leave the load as LDX.
This bug is causing a compile-time failure in the benchmark h264ref.
Details
Diff Detail
Event Timeline
This is added by QingShan Zhang in https://reviews.llvm.org/D49007, add him as reviewer.
llvm/lib/Target/PowerPC/PPCInstrInfo.cpp | ||
---|---|---|
3069 | isImmElgibleForForwarding() will check if the ImmMO is elgible for forwarding. And it will check the alignment there according to the restriction with different instructions. |
Please add a test case that we used to transform to a D-Form and no longer do with your patch (preferably one for DS-Form and one for DQ-Form).
llvm/lib/Target/PowerPC/PPCInstrInfo.cpp | ||
---|---|---|
3067 | This comment also needs to be updated. The instruction does not require the data to be aligned, it requires the displacement to be a multiple of 4. |
This comment also needs to be updated. The instruction does not require the data to be aligned, it requires the displacement to be a multiple of 4.
I suppose the problem is that unaligned data may reside at non-multiple-of-4 offsets from the base reg and we don't know yet if that is the case. However, adding the check here just shifts the bug because we could be handling an unaligned vector access with a DQ-Form instruction. If the data happens to be 4-byte aligned and the displacement ends up being 12, this check won't catch it and we're in just as much trouble.
So I am with Steven here that we should be doing the check in isImmElgibleForForwarding() where we have access to how this is being used and know what ImmMustBeMultipleOf.