llvm-svn: 284201

Lots of blocks had "llvm" or "nasm" syntax types but either weren't following
the syntax, or the syntax has changed (and sphinx hasn't keep up) or the type
doesn't even exist (nasm?).

Other documents had :options: what were invalid. I only removed those that had
warnings, and left the ones that didn't, in order to follow the principle of
least surprise.

This is like this for ages, but the buildbot is now failing on errors. It may
take a while to upgrade the buildbot's sphinx, if that's even possible, but
that shouldn't stop us from getting docs updates (which seem down for quite
a while).

Also, we're not losing any syntax highlight, since when it doesn't parse, it
doesn't colour. Ie. those blocks are not being highlighted anyway.

I'm trying to get all docs in one go, so that it's easy to revert later if we
do fix, or at least easy to know what's to fix.

llvm-svn: 276109

Add notead about the CoreCLR GC Strategy to the 
Garbage Collection document.

llvm-svn: 237869

Add a brief section linking to the experimental statepoint intrinsics analogous to the one we have linking to patchpoint.  

While I'm here, cleanup some wording about what the gc "name" attribute actually means.  It's not the name of a *collector* it's the name of the *strategy* which may be compatible with multiple collectors.

llvm-svn: 230576

llvm-svn: 230572

llvm-svn: 230570

I'd been using '' where I should have been using ``.

llvm-svn: 230407

Also, fix confusing bit of the gcroot documentation that bit me personally.

llvm-svn: 230405

llvm-svn: 230402

Mostly minor wording changes for readability.  Nothing major to see here.

llvm-svn: 230397

This is still gcroot vs gc.statepoint agnostic.  I'm just trying to clarify the general documentation at this point.

llvm-svn: 230393

In this change:
- Put the getting started section first
- Create a dedicated section to document the built in collector strategies
- Move discuss of ShadowStack into new section
- Add placeholders for erlang, ocaml, and statepoint-example collectors

There will be many more changes following.  I plan on full integrating the documentation for gc.statepoint and gc.root.  I want to make it much clearer on how to get started and what users should expect in terms of effort.

llvm-svn: 230359

This is a refactoring to restructure the single user of performCustomLowering as a specific lowering pass and remove the custom lowering hook entirely.

Before this change, the LowerIntrinsics pass (note to self: rename!) was essentially acting as a pass manager, but without being structured in terms of passes. Instead, it proxied calls to a set of GCStrategies internally. This adds a lot of conceptual complexity (i.e. GCStrategies are stateful!) for very little benefit. Since there's been interest in keeping the ShadowStackGC working, I extracting it's custom lowering pass into a dedicated pass and just added that to the pass order. It will only run for functions which opt-in to that gc.

I wasn't able to find an easy way to preserve the runtime registration of custom lowering functionality. Given that no user of this exists that I'm aware of, I made the choice to just remove that. If someone really cares, we can look at restoring it via dynamic pass registration in the future.

Note that despite the large diff, none of the lowering code actual changes. I added the framing needed to make it a pass and rename the class, but that's it.

Differential Revision: http://reviews.llvm.org/D7218

llvm-svn: 227351

information and update all callers. No functional change.

llvm-svn: 214781

llvm-svn: 212056

As an example that was not actually being used, it suffered from a slow bitrot.

The two main issues with it were that it had no cmake support and
included a copy of the autoconf directory. The reality is that
autoconf is not easily composable. The lack of composabilty is why we
have clang options in llvm's configure. Suggesting that users include
a copy of autoconf/ in their projects seems a bad idea.

We are also in the process of switching to cmake, so pushing autoconf
to new project is probably not what we want.

llvm-svn: 203728

llvm-svn: 193009

Update to reflect current GC APIs and usage. The example code is taken from the Erlang GC implementation.

llvm-svn: 193008

llvm-svn: 185854

against the developer policy to include this sort of thing as SVN blame
already captures this in a far more fine-grained way.

llvm-svn: 172109

Patch by Anthony Mykhailenko with small fixes by me.

llvm-svn: 169992

llvm-svn: 169932

Patch by Alexander Zinenko!

llvm-svn: 169702