d80e58b259c2febc4907aed4aca9d88d43bdd1a1 |
|
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
/frameworks/compile/slang/tests/P_reduce_general_examples/ScriptC_reduce_general_examples.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/ScriptC_reduce_general_examples.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/ScriptC_reduce_general_examples.java.expect
|
1381ae7c081ab151e78184501f757f517fe6c2a9 |
|
02-Feb-2016 |
David Gross <dgross@google.com> |
Remove array subrange (x1, x2) general reduction methods. The current implementation is functionally incorrect. A general reduction method that takes array inputs is implemented by creating a temporary Allocation for each input and initializing the Allocation from the input array. There is no efficient way to implement the array subrange methods today, because there is no efficient way to initialize an Allocation from a subrange of an array (see http://b/26804454). We would have to do something like: - Extend the RenderScript Java API; or - For each input array, create a temporary array, populate the temporary array from the appropriate subrange of the the original array, and initialize a temporary Allocation from the temporary array instead of the input array; or - For each input array, initialize an Allocation from the entire array, but use LaunchOptions to specify that only a subrange of the Allocation should be processed by the kernel. Bug: 23535724 Change-Id: Ie9d3ebe445724512bb196aa661a295f217145918
/frameworks/compile/slang/tests/P_reduce_general_examples/ScriptC_reduce_general_examples.java.expect
|
277fd5e6545c8ba1272027ee6e6bc55a96316dc0 |
|
14-Jan-2016 |
David Gross <dgross@google.com> |
Add Java reflection for "#pragma rs reduce". Also: - test.py now recognizes "Script*.java.expect" files as masters for comparing reflected code the same way "stderr.txt.expect" and "stdout.txt.expect" are masters for comparing compiler stderr and stdout. - gReflectionTypes[] now has a '"common name" in script (C99)' column (e.g., "short" is the common name by which a type appears in script code, in contrast with "int16_t" which is the name by which a type is reflected in NDK code). Bug: 23535724 Change-Id: I7960968bb98a17e33fe23415f7927cac537b72a3
/frameworks/compile/slang/tests/P_reduce_general_examples/ScriptC_reduce_general_examples.java.expect
|