This is an archive of the discontinued LLVM Phabricator instance.

Add a section to Statepoint docs mentioning shared bugzilla search and standard mailing lists
ClosedPublic

Authored by reames on Dec 3 2014, 4:50 PM.

Download Raw Diff

Details

Reviewers

Summary

This is extremely straightforward; I'm asking for review mostly because I haven't seen similar things elsewhere in the documentation. Anyone object or believe this is a bad idea?

Diff Detail

Event Timeline

reames updated this revision to Diff 16900.Dec 3 2014, 4:50 PM

reames retitled this revision from to Add a section to Statepoint docs mentioning shared bugzilla search and standard mailing lists.

reames updated this object.

reames edited the test plan for this revision. (Show Details)

reames added a subscriber: Unknown Object (MLST).

Go for it.

Closed via commit 223374

This revision is now accepted and ready to land.Dec 4 2014, 10:34 AM

reames closed this revision.Dec 29 2014, 6:23 PM

Revision Contents

Path

Size

docs/

Statepoints.rst

4 lines

Diff 16900

docs/Statepoints.rst

	Show First 20 Lines • Show All 199 Lines • ▼ Show 20 Lines
	To understand why this 'observable-after' property is required, consider a null comparison performed on the original copy of a relocated pointer. Assuming that control flow follows the safepoint, there is no way to observe externally whether the null comparison is performed before or after the safepoint. (Remember, the original Value is unmodified by the safepoint.) The compiler is free to make either scheduling choice.			To understand why this 'observable-after' property is required, consider a null comparison performed on the original copy of a relocated pointer. Assuming that control flow follows the safepoint, there is no way to observe externally whether the null comparison is performed before or after the safepoint. (Remember, the original Value is unmodified by the safepoint.) The compiler is free to make either scheduling choice.

	The actual correctness property implemented is slightly stronger than this. We require that there be no static path on which a potentially relocated pointer is 'observably-after' it may have been relocated. This is slightly stronger than is strictly necessary (and thus may disallow some otherwise valid programs), but greatly simplifies reasoning about correctness of the compiled code.			The actual correctness property implemented is slightly stronger than this. We require that there be no static path on which a potentially relocated pointer is 'observably-after' it may have been relocated. This is slightly stronger than is strictly necessary (and thus may disallow some otherwise valid programs), but greatly simplifies reasoning about correctness of the compiled code.

	By construction, this property will be upheld by the optimizer if correctly established in the source IR. This is a key invariant of the design.			By construction, this property will be upheld by the optimizer if correctly established in the source IR. This is a key invariant of the design.

	The existing IR Verifier pass has been extended to check most of the local restrictions on the intrinsics mentioned in their respective documentation. The current implementation in LLVM does not check the key relocation invariant, but this is ongoing work on developing such a verifier. Please ask on llvmdev if you're interested in experimenting with the current version.			The existing IR Verifier pass has been extended to check most of the local restrictions on the intrinsics mentioned in their respective documentation. The current implementation in LLVM does not check the key relocation invariant, but this is ongoing work on developing such a verifier. Please ask on llvmdev if you're interested in experimenting with the current version.

				Bugs and Enhancements
				=====================
				Currently known bugs and enhancements under consideration can be tracked by performing a `bugzilla search <http://llvm.org/bugs/buglist.cgi?cmdtype=runnamed&namedcmd=Statepoint%20Bugs&list_id=64342>`_ for [Statepoint] in the summary field. When filing new bugs, please use this tag so that interested parties see the newly filed bug. As with most LLVM features, design discussions take place on `llvmdev <http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>`_, and patches should be sent to `llvm-commits <http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits>`_ for review.