This is an archive of the discontinued LLVM Phabricator instance.

Fix for assertion when compiling for Thumb1, with a processor with a VFP unit
ClosedPublic

Authored by olista01 on Jun 5 2014, 3:04 AM.

Details

Reviewers
sgundapa
Summary

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.

Diff Detail

Event Timeline

olista01 updated this revision to Diff 10131.Jun 5 2014, 3:04 AM
olista01 retitled this revision from to Fix for assertion when compiling for Thumb1, with a processor with a VFP unit.
olista01 updated this object.
olista01 edited the test plan for this revision. (Show Details)
olista01 added a subscriber: Unknown Object (MLST).
olista01 updated this revision to Diff 10132.Jun 5 2014, 3:22 AM

Fixed typo in filename.

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 ?

sgundapa accepted this revision.Jun 12 2014, 10:14 AM
sgundapa added a reviewer: sgundapa.
This revision is now accepted and ready to land.Jun 12 2014, 10:14 AM
olista01 closed this revision.Jun 13 2014, 1:41 AM

Thanks, committed revision 210889.