diff options
author | Ranjeet Singh <Ranjeet.Singh@arm.com> | 2017-03-03 11:40:07 +0000 |
---|---|---|
committer | Ranjeet Singh <Ranjeet.Singh@arm.com> | 2017-03-03 11:40:07 +0000 |
commit | 7b60a9ed0c0584fc5fd4b87e0019aad99b6be1e4 (patch) | |
tree | b52b5ee7fa46a105b2fc8ba553f7419cf446bfd6 /lldb/packages/Python/lldbsuite/test/sample_test/TestSampleInlineTest.py | |
parent | 17a4b2344e8a4d6b2b6e23bf50d4e77d0a1879c4 (diff) | |
download | bcm5719-llvm-7b60a9ed0c0584fc5fd4b87e0019aad99b6be1e4.tar.gz bcm5719-llvm-7b60a9ed0c0584fc5fd4b87e0019aad99b6be1e4.zip |
[ARM] fpscr read/write intrinsics not aware of each other
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
Diffstat (limited to 'lldb/packages/Python/lldbsuite/test/sample_test/TestSampleInlineTest.py')
0 files changed, 0 insertions, 0 deletions