On Dec 10, 3:56 pm, Dan Grayson <d...@math.uiuc.edu> wrote:
> He could also mean that the machine instructions that move 8 byte
> words to vector registers would segfault if you tried to use them on
> nonaligned data, and that he tried to write mpn_lshift to try to avoid
> doing that. Those are the lines of code I pointed to in the original
> report. It would be a bug to write code that depended on alignment,
> as I pointed out, unless you change the documentation about custom
> memory allocators, which should not be done lightly.
>
> On Dec 10, 9:43 am, Bill Hart <goodwillh...@googlemail.com> wrote:
>
>
>
> > I found the following in correspondence with Jason (I can't just ask
> > him, as his internet seems to be offline at the moment):
>
> > "Misaligned data will segfault on some arches and instructions eg K10
> > and lshift"
>
> > So presumably he has assumed data is aligned on K10, written a fast
> > version of the code for this case, then propagated it to other arches
> > where no segfault will occur. Actually, I am unsure whether that is
> > what he means, but that is what I infer.
>
> > If so, the solution would seem to be to replace the Core2 and Atom
> > code with a safer version and leave the K10 code as is. That's really
> > something Jason should do though, so we probably have to wait for him
> > to pop up again.- Hide quoted text -
>
> - Show quoted text -
Looking at the code, it seems to me that it has been designed for
doing 16 byte operations that are at least 8 byte aligned. This is
what I would expect in 64-bit assembler code, which an reasonably be
designed to rely on 8-byte alignment.
Moreover, Jason's code does appear to account for any additional 8-
byte segments are needed at the start or the end of a sequence of 16-
byte aligned operations.
So it looks to me like a code bug rather than a documentation bug.
But the Custom Allocation section of tthe manual says nothing at all
about alignment. It doesn't even require that limb allocations are
properly aligned on the target machine - i.e. 4 byte alignment in 32-
bit MPIR and 8 byte alignment in 64-bit MPIR!
I suspect a lot of the assembler code won't deal well (if at all) with
mis-aligned limbs so we should surely say something about this in the
documentation of Custom Allocation. In my view we should indicate
that use of assembler code is suspect if memory allocation does not
ensure correct limb alignment - i.e. n byte limbs should be at least n
byte aligned.
Brian
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To post to this group, send email to mpir-de...@googlegroups.com.
To unsubscribe from this group, send email to
mpir-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/mpir-devel?hl=en.
