| 6a360ef49a83c623784ce97e32f7c07b170ef364 |
|
24-Jul-2017 |
David Gross <dgross@google.com> |
Improve Java reflection for 32-bit versus 64-bit differences.
Bug: 32780232
Bug: 20260865
Bug: 21597073
By default, when targeting API L or above, we support both 32-bit and
64-bit targets. We do so by running two compilation passes -- a
32-bit compilation pass followed by a 64-bit compilation pass. We
generate reflected Java code as part of the 64-bit compilation pass.
This can cause problems if there are "significant" differences between
the user's script (.rs file) as seen during 32-bit compilation
compared to 64-bit compilation -- for example, rs object handles (such
as rs_allocation and rs_element) are different sizes, the type size_t
is a different size, and a user can create arbitrary differences by
using the __LP64__ macro. If any of those differences affect
reflected code (for example, by changing exported types), then we may
get incorrect runtime behavior on 32-bit targets.
At present we do have some special processing for rs object handles.
However, we don't properly address all cases -- for example, when an
rs object handle is a field of a struct or an argument to an invokable
function, reflected code does not get the layout of the struct or
argument list correct on 32-bit targets. We also make no attempt to
address any other differences (such as size_t or __LP64__).
This CL is intended to fully address 32-bit versus 64-bit reflection
issues:
1) Fully handle rs object handle size differences when laying out data
(such as structs and invokable function argument lists).
2) Emit errors for any other differences between 32-bit and 64-bit
compilation that would require changes to reflected code (for
example, no exported global may be of type size_t).
We solve these problems as follows:
a) As part of the 32-bit compilation pass, execute (most of) the same
code paths we would use to generate reflected code, but instead of
actually generating reflected code, collect information for later.
b) When we generate reflected code as part of the 64-bit compilation
pass, we consult the information collected during the 32-bit
compilation pass in order to do target sensitive data layout and to
emit errors for intolerable 32-bit versus 64-bit differences.
This CL requires changes to the compatibility library (in
frameworks/rs).
Test: many
- slang/lit-tests
- slang/test
- RsTest aosp_x86_64-eng (aosp, emulator) 32-bit and 64-bit
- cts aosp_x86_64-eng (aosp, emulator) RenderScript and CtsRsCppTestCases
- RSTestBackward
- aosp_arm-eng
- n9 LMP MR1 Release (LM)
- angler MNC DR Release (MD)
- aosp_arm64-eng
- n9 LMP MR1 Release (LM)
- angler MNC DR Release (MD)
- RSTest_Backward19
- aosp_arm-eng
- n5 KLP MR2 Release (KT)
- n9 LMP MR1 Release (LM)
- angler MNC DR Release (MD)
- RSTest_CompatLib
- aosp_arm-eng
- n9 LMP MR1 Release (LM)
- angler MNC DR Release (MD)
- aosp_arm64-eng
- n9 LMP MR1 Release (LM)
- angler MNC DR Release (MD)
- aosp_x86-eng
- emulator aosp
- aosp_x86_64-eng
- emulator aosp
- RSTest_Compat19
- aosp_arm-eng
- n5 KLP MR2 Release (KT)
- n9 LMP MR1 Release (LM)
- angler MNC DR Release (MD)
- aosp_x86
- emulator aosp
Change-Id: I5d1fc51e35693588dff05afa48e1a4902859036e
(cherry picked from commit d80e58b259c2febc4907aed4aca9d88d43bdd1a1)
/frameworks/compile/slang/tests/P_reduce_general_examples_backward/ScriptC_reduce_general_examples_backward.java.expect
|
| 8ee018bdb53fc5abdc430878e2bec0c0c0aa560f |
|
02-Jun-2016 |
David Gross <dgross@google.com> |
Delete simple reduction implementation.
Bug: 27298560
Change-Id: I775dd782d658c7c720f57aa31a584deee98cdd17
/frameworks/compile/slang/tests/P_reduce_general_examples_backward/ScriptC_reduce_general_examples_backward.java.expect
|
| d204e65f7b46a3592a254d581e4b9f2af92b6eac |
|
07-Apr-2016 |
David Gross <dgross@google.com> |
Reflected result_* class should destroy() temporary Allocations at the end of get().
Also ensure that only the first call to get() does the work to
extract the actual result from the output Allocation.
Bug: 27973904
Change-Id: I0ef0d9e646db29973158504069261751a09585d2
/frameworks/compile/slang/tests/P_reduce_general_examples_backward/ScriptC_reduce_general_examples_backward.java.expect
|
| 5e306b944425a952fe744f59d828538137a59375 |
|
09-Feb-2016 |
David Gross <dgross@google.com> |
Change mechanism used to ensure #pragma rs reduce functions are not deleted.
Requires corresponding change in frameworks/compile/libbcc.
The functions referenced by "#pragma rs reduce" are static functions.
If the only references to such a function are from these pragmas, then
the function looks unreferenced, and hence without additional work
will be deleted by clang.
The old solution to this problem is to add all such functions to
the LLVM intrinsic variable @llvm.used. Unfortunately, this
doesn't just prevent clang from deleting these functions -- it
also prevents llvm from deleting these functions. This is
undesirable in the case of the combiner function (which is not
currently needed by the CPU reference driver) or the accumulator
function (because the CPU reference driver needs an "expanded"
form of the accumulator function, not the original accumulator
function).
The new solution is that for each such function "f" we generate a
dummy variable initialized with a pointer to that function:
void *.rs.reduce_fn.f = (void*)&f;
This prevents clang from deleting "f", but does not automatically
prevent llvm from deleting "f" (e.g., the backend could use some
other mechanism to retain "f" if necessary, while
deleting ".rs.reduce_fn.f").
Bug: 23535724
(cherry picked from commit 633f2980e148775887f0d416f8dd663a6d3b48df)
Change-Id: I272445d2bf706cde8d81ed65aa32df59c3ba0e47
/frameworks/compile/slang/tests/P_reduce_general_examples_backward/ScriptC_reduce_general_examples_backward.java.expect
|