Re: [pypy-dev] [pypy-commit] pypy default: Hack to ensure that ll_arraycopy gets a proper effectinfo.write_descrs_arrays
Hi, is there a better way to fix this? The same kind of issue might arise elsewhere?
Author: Hakan Ardo <hakan at debian.org> Branch: Changeset: r47722:bf3f65e2b1c2 Date: 2011-09-30 19:48 +0200 http://bitbucket.org/pypy/pypy/changeset/bf3f65e2b1c2/
Log: Hack to ensure that ll_arraycopy gets a proper effectinfo.write_descrs_arrays
diff --git a/pypy/rlib/rgc.py b/pypy/rlib/rgc.py --- a/pypy/rlib/rgc.py +++ b/pypy/rlib/rgc.py @@ -143,6 +143,10 @@ from pypy.rpython.lltypesystem.lloperation import llop from pypy.rlib.objectmodel import keepalive_until_here
+ # XXX: Hack to ensure that we get a proper effectinfo.write_descrs_arrays + if length > 0: + dest[dest_start] = source[source_start] + # supports non-overlapping copies only if not we_are_translated(): if source == dest:
-- Håkan Ardö
On Fri, Sep 30, 2011 at 6:15 PM, Hakan Ardo <hakan@debian.org> wrote:
Hi, is there a better way to fix this? The same kind of issue might arise elsewhere?
Make sure that raw_memcopy has the correct effect on analyzer?
Author: Hakan Ardo <hakan at debian.org> Branch: Changeset: r47722:bf3f65e2b1c2 Date: 2011-09-30 19:48 +0200 http://bitbucket.org/pypy/pypy/changeset/bf3f65e2b1c2/
Log: Hack to ensure that ll_arraycopy gets a proper effectinfo.write_descrs_arrays
diff --git a/pypy/rlib/rgc.py b/pypy/rlib/rgc.py --- a/pypy/rlib/rgc.py +++ b/pypy/rlib/rgc.py @@ -143,6 +143,10 @@ from pypy.rpython.lltypesystem.lloperation import llop from pypy.rlib.objectmodel import keepalive_until_here
+ # XXX: Hack to ensure that we get a proper effectinfo.write_descrs_arrays + if length > 0: + dest[dest_start] = source[source_start] + # supports non-overlapping copies only if not we_are_translated(): if source == dest:
-- Håkan Ardö _______________________________________________ pypy-dev mailing list pypy-dev@python.org http://mail.python.org/mailman/listinfo/pypy-dev
On Fri, Sep 30, 2011 at 11:17 PM, Maciej Fijalkowski <fijall@gmail.com> wrote:
On Fri, Sep 30, 2011 at 6:15 PM, Hakan Ardo <hakan@debian.org> wrote:
Hi, is there a better way to fix this? The same kind of issue might arise elsewhere?
Make sure that raw_memcopy has the correct effect on analyzer?
What effect would that be? Setting extraeffect=EF_RANDOM_EFFECTS as it can write anywhere? Can I then somehow give ll_arraycopy a more restrictive effectinfo? -- Håkan Ardö
On Sat, Oct 1, 2011 at 4:38 AM, Hakan Ardo <hakan@debian.org> wrote:
On Fri, Sep 30, 2011 at 11:17 PM, Maciej Fijalkowski <fijall@gmail.com> wrote:
On Fri, Sep 30, 2011 at 6:15 PM, Hakan Ardo <hakan@debian.org> wrote:
Hi, is there a better way to fix this? The same kind of issue might arise elsewhere?
Make sure that raw_memcopy has the correct effect on analyzer?
What effect would that be? Setting extraeffect=EF_RANDOM_EFFECTS as it can write anywhere? Can I then somehow give ll_arraycopy a more restrictive effectinfo?
Armin commited this on trunk: 78fddfb51114
-- Håkan Ardö
On Sat, Oct 1, 2011 at 1:27 PM, Maciej Fijalkowski <fijall@gmail.com> wrote:
On Sat, Oct 1, 2011 at 4:38 AM, Hakan Ardo <hakan@debian.org> wrote:
On Fri, Sep 30, 2011 at 11:17 PM, Maciej Fijalkowski <fijall@gmail.com> wrote:
On Fri, Sep 30, 2011 at 6:15 PM, Hakan Ardo <hakan@debian.org> wrote:
Hi, is there a better way to fix this? The same kind of issue might arise elsewhere?
Make sure that raw_memcopy has the correct effect on analyzer?
What effect would that be? Setting extraeffect=EF_RANDOM_EFFECTS as it can write anywhere? Can I then somehow give ll_arraycopy a more restrictive effectinfo?
Armin commited this on trunk: 78fddfb51114
Yes that improves the hack. However it still makes me concerned about any other (potential future) usages of raw_memcopy. Wont they have the same issue? How about we set extraeffect=EF_RANDOM_EFFECTS in the effectinfo of raw_memcopy and introduces a decorator that would allow us to lessen the effect inhertited by a function calling it. Something like: def raw_memcopy_effect_in_arraycopy(source, dest, source_start, dest_start, length): dest[dest_start] = source[source_start] @replace_inherited_effect_of(raw_memcopy, with=raw_memcopy_effect_in_arraycopy) def ll_arraycopy(source, dest, source_start, dest_start, length): ... raw_memcopy(...) -- Håkan Ardö
On Tue, Oct 4, 2011 at 12:00 AM, Hakan Ardo <hakan@debian.org> wrote:
On Sat, Oct 1, 2011 at 1:27 PM, Maciej Fijalkowski <fijall@gmail.com> wrote:
On Sat, Oct 1, 2011 at 4:38 AM, Hakan Ardo <hakan@debian.org> wrote:
On Fri, Sep 30, 2011 at 11:17 PM, Maciej Fijalkowski <fijall@gmail.com> wrote:
On Fri, Sep 30, 2011 at 6:15 PM, Hakan Ardo <hakan@debian.org> wrote:
Hi, is there a better way to fix this? The same kind of issue might arise elsewhere?
Make sure that raw_memcopy has the correct effect on analyzer?
What effect would that be? Setting extraeffect=EF_RANDOM_EFFECTS as it can write anywhere? Can I then somehow give ll_arraycopy a more restrictive effectinfo?
Armin commited this on trunk: 78fddfb51114
Yes that improves the hack. However it still makes me concerned about any other (potential future) usages of raw_memcopy. Wont they have the same issue?
How about we set extraeffect=EF_RANDOM_EFFECTS in the effectinfo of raw_memcopy and introduces a decorator that would allow us to lessen the effect inhertited by a function calling it. Something like:
def raw_memcopy_effect_in_arraycopy(source, dest, source_start, dest_start, length): dest[dest_start] = source[source_start]
@replace_inherited_effect_of(raw_memcopy, with=raw_memcopy_effect_in_arraycopy) def ll_arraycopy(source, dest, source_start, dest_start, length): ... raw_memcopy(...)
-- Håkan Ardö
How many usages of raw_memcopy are there? I guess not very many
participants (2)
-
Hakan Ardo -
Maciej Fijalkowski