I don't have any knowledge of fp128 (why do we need -mattr=mmx?) or what's supposed to be happening in these tests, so I assumed we should just run away from this possibility.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
lib/Target/X86/X86ISelLowering.cpp | ||
---|---|---|
35229 ↗ | (On Diff #118500) | Does this work? if (peekThroughBitcasts(X).getValueType() == MVT::f128) || peekThroughBitcasts(Y).getValueType() == MVT::f128)) |
lib/Target/X86/X86ISelLowering.cpp | ||
---|---|---|
35229 ↗ | (On Diff #118500) | Yes - that's better, thanks...and reminds me to chase down the remaining blockers for removing the loop in there. |
Patch updated:
Use peekThroughBitcasts() to make the code shorter and more robust.
Note:
I found this as the source of the MMX requirement, but I'm still not sure what is expected from these tests (other than not crashing):
// Long double always uses X87, except f128 in MMX. if (UseX87) { if (Subtarget.is64Bit() && Subtarget.hasMMX()) { addRegisterClass(MVT::f128, &X86::FR128RegClass); ValueTypeActions.setTypeAction(MVT::f128, TypeSoftenFloat);
...for the no-mmx target, we would generate:
movq %rsi, %xmm0 movq %rdi, %xmm1 punpcklqdq %xmm0, %xmm1 ## xmm1 = xmm1[0],xmm0[0] pxor %xmm0, %xmm0 pcmpeqb %xmm1, %xmm0 pmovmskb %xmm0, %eax cmpl $65535, %eax ## imm = 0xFFFF sete %al retq
This change LGTM.
I added more comments in https://bugs.llvm.org/show_bug.cgi?id=34866.
Note that fp128-cast.ll tests only cover the cases with +mmx.
If the original change in D31156 could affect fp128 and no-mmx cases,
it would be better to add test cases for clang -mno-mmx and/or -mno-sse.
Thanks for the explanation. And yes, D31156 has no dependency on mmx. I'll add a no-mmx RUN for this file.