This is a fix for http://llvm.org/bugs/show_bug.cgi?id=19935, which is caused by the fastcc calling convention being converted to AAPCS-VFP when targeting the Thumb1 instruction set, which cannot access the floating-point registers.
Details
Diff Detail
Event Timeline
Hi Oliver,
I've not checked, but does this require a corresponding Clang change? It decides whether to emit an explicit calling-convention marker based on its understanding of what LLVM will use by default. I *think* getLLVMDefaultCC is the relevant function.
Cheers.
Tim.
Wouldn't it be simpler (and more explicit) to early return with:
if (Subtarget->isThumb1Only()) return CallingConv::ARM_AAPCS;
?
Does this require a corresponding Clang change?
Clang already does not seem to take into account whether a VFP unit is present, so I don't think that this patch requires a clang change.
However, a bit of experimentation shows that it is possible to make things go very wrong by specifying a hard-float calling convention with an architecture which does not support it. The problems are not limited to clang making assumptions about llvm's default calling convention. There should probably be some logic in clang to make sure the user is not trying to do something architecturally impossible, but that is a bigger issue than this patch.
Wouldn't it be simpler (and more explicit) to early return?
There is still one case in which we return CallingConv::ARM_APCS rather than CallingConv::ARM_AAPCS, so I don't think this would simplify things.
The assertions in my validations are gone with this patch.
Can some one merge this to mainline if you are not planning to update this patch further ?