Displaying 3 results from an estimated 3 matches for "duktape".
2018 Feb 02
0
llvm.memcpy for struct copy
...] argument, whereas the other version takes only i8* and i8 in registers. This means that if the callee writes the data out to memory and then performs a memcmp, the 8-byte-pointer version may not have the same padding, whereas the 16-byte-pointer version will.
In the code that we were using (the DukTape JavaScript interpreter), the callee didn’t actually look at the padding bytes in either case, so we just ended up with less efficient code in the 16-byte-pointer case, but the same could equally have generated incorrect code for the 8-byte-pointer case.
David
2018 Feb 01
2
llvm.memcpy for struct copy
On 2/1/2018 2:03 AM, David Chisnall via llvm-dev wrote:
> In contrast, the padding between fields in non-packed structs
> disappears as soon as SROA runs. This can lead to violations of C
> semantics, where padding fields should not change (because C defines
> bitwise comparisons on structs using memcmp). This can lead to subtly
> different behaviour in C code depending on the
2018 Feb 03
2
llvm-dev Digest, Vol 164, Issue 6
...nd i8 in
> > registers. This means that if the callee writes the data out to memory
> and
> > then performs a memcmp, the 8-byte-pointer version may not have the same
> > padding, whereas the 16-byte-pointer version will.
> >
> > In the code that we were using (the DukTape JavaScript interpreter), the
> > callee didn’t actually look at the padding bytes in either case, so we
> just
> > ended up with less efficient code in the 16-byte-pointer case, but the
> same
> > could equally have generated incorrect code for the 8-byte-pointer case.
>...