Author: Armin Rigo <ar...@tunes.org> Branch: arm64 Changeset: r96952:dbb6f23ca77d Date: 2019-07-05 08:35 +0200 http://bitbucket.org/pypy/pypy/changeset/dbb6f23ca77d/
Log: This is done diff --git a/rpython/jit/backend/aarch64/TODO b/rpython/jit/backend/aarch64/TODO --- a/rpython/jit/backend/aarch64/TODO +++ b/rpython/jit/backend/aarch64/TODO @@ -16,26 +16,6 @@ _build_failure_recovery(), build_frame_realloc_slowpath(), etc. -* here's what gcc uses to acquire and release a lock, instead of mc.DMB - in callbuilder.py. It would make the control flow mess easier, too, - because we can simply loop back to .L2 (rare case) instead of trying - to handle it as a 3rd path. - - to release a lock: - (x0 is the address of the lock) - stlr xzr, [x0] - - to acquire a lock: - (x1 is the address of the lock) - mov x2, 1 - .L2: ldxr x0, [x1] - stxr w3, x2, [x1] - cbnz w3, .L2 (I think it's a rare case when it follows .L2) - dmb ish (see below) - (we're left with x0 being the old value in the lock, 0 or 1) - - note that "dmb" only appears sometimes, depending on the exact gcc - intrinsic I use. I *think* that it can be safely removed, and so - it should be. - - * malloc_cond() and malloc_cond_varsize_frame() hard-code forward jump distances by guessing the number of instructions that follows. Bad idea because some of these instructions could easily be optimized in _______________________________________________ pypy-commit mailing list pypy-commit@python.org https://mail.python.org/mailman/listinfo/pypy-commit
