summaryrefslogtreecommitdiffstats
path: root/llvm/test/CodeGen/ARM/fpscr-intrinsics.ll
Commit message (Collapse)AuthorAgeFilesLines
* [ARM] Reapply r296865 "[ARM] fpscr read/write intrinsics not aware of each ↵Ranjeet Singh2017-03-071-0/+44
| | | | | | | | | | | | | | | | | | | | other"" The original patch r296865 was reverted as it broke the chromium builds for Android https://bugs.llvm.org/show_bug.cgi?id=32134, this patch reapplies r296865 with a fix to make sure it doesn't cause the build regression. The problem was that intrinsic selection on int_arm_get_fpscr was failing in ISel this was because the code to manually select this intrinsic still thought it was the version with no side-effects (INTRINSIC_WO_CHAIN) which is wrong as it doesn't semantically match the definition in the tablegen code which says it does have side-effects, I've fixed this by updating the intrinsic type to INTRINSIC_W_CHAIN (has side-effects). I've also added a test for this based on Hans original reproducer. Differential Revision: https://reviews.llvm.org/D30645 llvm-svn: 297137
* Revert r296865 "[ARM] fpscr read/write intrinsics not aware of each other"Hans Wennborg2017-03-031-23/+0
| | | | | | It caused PR32134: "Cannot select: intrinsic %llvm.arm.get.fpscr". llvm-svn: 296926
* [ARM] fpscr read/write intrinsics not aware of each otherRanjeet Singh2017-03-031-0/+23
The intrinsics __builtin_arm_get_fpscr and __builtin_arm_set_fpscr read and write to the fpscr (Floating-Point Status and Control Register) register. A bug exists in the __builtin_arm_get_fpscr intrinsic definition in llvm which treats this intrinsic as a IntroNoMem which means it's not a memory access and doesn't have any other side-effects. Having this property on this intrinsic means that various optimizations can be done on this such as common sub-expression elimination with other reads. This can cause issues if there has been write to this register, e.g. void foo(int *p) { p[0] = __builtin_arm_get_fpscr(); __builtin_arm_set_fpscr(1); p[1] = __builtin_arm_get_fpscr(); } in the above example the second read is currently CSE'd into the first read, this is because llvm isn't aware that the write done by __builtin_arm_set_fpscr effects the same register that __builtin_arm_get_fpscr reads from, to fix this problem I've removed the property IntrNoMem so that __builtin_arm_get_fpscr is treated as a memory access. Differential Revision: https://reviews.llvm.org/D30542 llvm-svn: 296865
OpenPOWER on IntegriCloud