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

llvm-svn: 244292

llvm-svn: 243999

Add FaultMaps.rst to toctree.

llvm-svn: 239747

llvm-svn: 239657

Summary:
Move lib/Fuzzer docs from a README.txt to a proper .rst file.
This change does not add any content, just formatting.

Test Plan: n/a

Reviewers: samsonov

Reviewed By: samsonov

Subscribers: llvm-commits

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

llvm-svn: 233638

Reviewers: chandlerc, samsonov, echristo

Reviewed By: samsonov

Subscribers: emaste, joker.eph, llvm-commits

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

llvm-svn: 232135

As mentioned on llvm-dev, this is a new documentation page intended to collect tips for frontend authors on how to generate IR that LLVM is able to optimize well. These types of things come up repeated in review threads and it would be good to have a place to save them.

I added a small handful to start us off, but I mostly want to get the framework in place. Once the docs are here, we can add to them incrementally.  If you know of something appropriate for this page, please add it!

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

llvm-svn: 230807

This patch introduces a new mechanism that allows IR modules to co-operatively
build pointer sets corresponding to addresses within a given set of
globals. One particular use case for this is to allow a C++ program to
efficiently verify (at each call site) that a vtable pointer is in the set
of valid vtable pointers for the class or its derived classes. One way of
doing this is for a toolchain component to build, for each class, a bit set
that maps to the memory region allocated for the vtables, such that each 1
bit in the bit set maps to a valid vtable for that class, and lay out the
vtables next to each other, to minimize the total size of the bit sets.

The patch introduces a metadata format for representing pointer sets, an
'@llvm.bitset.test' intrinsic and an LTO lowering pass that lays out the globals
and builds the bitsets, and documents the new feature.

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

llvm-svn: 230054

llvm-svn: 228192

llvm-svn: 225815

Pass looks for equivalent functions that are mergable and folds them.

llvm-svn: 223931

It was complaining it wasn't included in any toctree

llvm-svn: 223254

This was done using the Sparc and PowerPC AsmParsers as guides.  So far it
is very simple and only supports sopp instructions.

llvm-svn: 221994

llvm-svn: 219015

llvm-svn: 218504

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

llvm-svn: 215990

There are some interesting decisions based on non-obvious rationale in
the ARM64-BE NEON implementation - decent documentation is definitely required.

llvm-svn: 208577

Documents terminology used in the forthcoming rewrite of
BlockFrequencyInfo.

<rdar://problem/14292693>

llvm-svn: 206086

docs/TableGen/ is not really just "fundamentals" anymore, but rather
more of a portal for all things TableGen.

llvm-svn: 205743

Making the new TableGen documentation official and marking the old file as
"Moved". Also, reverting the original LangRef as the normative formal
description of the language, while keeping the "new" LangRef as LangIntro
for the less inlcined to reading language grammars.

We should remove TableGenFundamentals.rst one day, but for now, just a
warning that it moved will have to do, while we make sure there are no more
links to it from elsewhere.

llvm-svn: 205289

This is mainly a movement of content around to give place to new content
allowing different people to add bits to it in the right place. There is some
new content, but mostly to fill the gaps left by text movement.

I'm dropping the old syntax documentation as it has the problem of being
quickly outdated by changes and largely unnecessary to people not involved
in creating the language, but using it, which is the whole point of the
documentation.

llvm-svn: 204351

The docs now build cleanly. Yay!

The following warnings were fixed:

/home/sean/pg/llvm/llvm/docs/HowToReleaseLLVM.rst:364: WARNING: Enumerated list ends without a blank line; unexpected unindent.
/home/sean/pg/llvm/llvm/docs/InAlloca.rst:: WARNING: document isn't included in any toctree

/home/sean/pg/llvm/llvm/docs/CodingStandards.rst:85: WARNING: Title underline too short.

Supported C++11 Language and Library Features
-------------------------------------------
/home/sean/pg/llvm/llvm/docs/CodingStandards.rst:85: WARNING: Title underline too short.

Supported C++11 Language and Library Features
-------------------------------------------
/home/sean/pg/llvm/llvm/docs/GettingStarted.rst:185: WARNING: Explicit markup ends without a blank line; unexpected unindent.
/home/sean/pg/llvm/llvm/docs/GettingStarted.rst:565: WARNING: Explicit markup ends without a blank line; unexpected unindent.
/home/sean/pg/llvm/llvm/docs/GettingStarted.rst:567: WARNING: Block quote ends without a blank line; unexpected unindent.

llvm-svn: 202603

These still have "experimental" status, meaning we don't guarantee
backward compatibility. However, they are already actively used by the
open source WebKit project, and have started to be adopted by other
projects.

llvm-svn: 197930

llvm-svn: 190326

llvm-svn: 190282

llvm-svn: 188943

llvm-svn: 182763

Add support for the COFF relocation types IMAGE_REL_I386_DIR32NB and
IMAGE_REL_AMD64_ADDR32NB for 32- and 64-bit respectively. These are
similar to normal 4-byte relocations except that they do not include
the base address of the image.

Image-relative relocations are used for debug information (32-bit) and
SEH unwind tables (64-bit).

A new MCSymbolRef variant called 'VK_COFF_IMGREL32' is introduced to
specify such relocations. For AT&T assembly, this variant can be accessed
using the symbol suffix '@imgrel'.

llvm-svn: 179240

Summary: This is the beginning of user documentation for the NVPTX back-end.  I want to ensure I am integrating this properly into the rest of the LLVM documentation.

Differential Revision: http://llvm-reviews.chandlerc.com/D600

llvm-svn: 178428

llvm-svn: 178426

Nobody says "the developer's list" or "commits archive"; they always say
"llvmdev" or "llvm-commits". It makes sense for our documentation to
at least make that association explicitly.

llvm-svn: 178425

Order them roughly by "which one should a newbie join first".

llvm-svn: 178424

llvm-svn: 178423

llvm-svn: 178422

llvm-svn: 178421

This is based on Bill Wendling's email.  No additional content has been added,
but now there's a place for Attributes to capture future information.

llvm-svn: 174961

llvm-svn: 173718

llvm-svn: 172970

These are really definition lists.

llvm-svn: 172950

This brings back {Ctrl,Cmd}-f'ability, and makes some really bad
organizational choices easier to see (and therefore fix).

llvm-svn: 172949