summaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
authorCharles Harris <charlesr.harris@gmail.com>2019-01-03 12:19:04 -0700
committerGitHub <noreply@github.com>2019-01-03 12:19:04 -0700
commitfd89a4137969b676d4449e2b61ecd7f4c5811d7a (patch)
tree13329a3b1d69cc1552f8388ace78ebb16d9bf8f3 /doc
parent0ea890a7b8a26f45e05c71075994e5be863fd49b (diff)
parent812e359b50919fb99942c674098ce8b8c506ab5d (diff)
downloadnumpy-fd89a4137969b676d4449e2b61ecd7f4c5811d7a.tar.gz
Merge pull request #12626 from ahaldane/further_uint_align_fix
BUG: fix uint alignment asserts in lowlevel loops
Diffstat (limited to 'doc')
-rw-r--r--doc/source/reference/alignment.rst24
1 files changed, 15 insertions, 9 deletions
diff --git a/doc/source/reference/alignment.rst b/doc/source/reference/alignment.rst
index c749972b4..b182a1e7b 100644
--- a/doc/source/reference/alignment.rst
+++ b/doc/source/reference/alignment.rst
@@ -34,6 +34,14 @@ datatype is implemented as ``struct { float real, imag; }``. This has "true"
alignment of 4 and "uint" alignment of 8 (equal to the true alignment of
``uint64``).
+Some cases where uint and true alignment are different (default gcc linux):
+ arch type true-aln uint-aln
+ ---- ---- -------- --------
+ x86_64 complex64 4 8
+ x86_64 float128 16 8
+ x86 float96 4 -
+
+
Variables in Numpy which control and describe alignment
-------------------------------------------------------
@@ -82,17 +90,15 @@ Here is how the variables above are used:
appropriate N. Otherwise numpy copies by doing ``memcpy(dst, src, N)``.
5. Nditer code: Since this often calls the strided copy code, it must
check for "uint alignment".
- 6. Cast code: if the array is "uint aligned" this will essentially do
- ``*dst = CASTFUNC(*src)``. If not, it does
+ 6. Cast code: This checks for "true" alignment, as it does
+ ``*dst = CASTFUNC(*src)`` if aligned. Otherwise, it does
``memmove(srcval, src); dstval = CASTFUNC(srcval); memmove(dst, dstval)``
where dstval/srcval are aligned.
-Note that in principle, only "true alignment" is required for casting code.
-However, because the casting code and copy code are deeply intertwined they
-both use "uint" alignment. This should be safe assuming uint alignment is
-always larger than true alignment, though it can cause unnecessary buffering if
-an array is "true aligned" but not "uint aligned". If there is ever a big
-rewrite of this code it would be good to allow them to use different
-alignments.
+Note that the strided-copy and strided-cast code are deeply intertwined and so
+any arrays being processed by them must be both uint and true aligned, even
+though te copy-code only needs uint alignment and the cast code only true
+alignment. If there is ever a big rewrite of this code it would be good to
+allow them to use different alignments.