llvm-svn: 202537

llvm-svn: 202532

llvm-svn: 202531

A lot of this is writing down common knowledge and things often
communicated on mailing lists and in discussions. It could live in the
Programmer's Manual alternatively, but that felt slightly less
well-fitting.

It also includes (and was motivated by) the section on the relevant
language standards for LLVM and the specific features that will be
enabled with the switch to C++11.

With this, all of the documentation for the C++11 switch is, I think, in
place. I plan to flip the switch RSN. =]

llvm-svn: 202497

standards.

It claims the document intentionally doesn't give fixed standards for
brace placement or spacing, and then the document goes on to do
precisely that in several places. Instead, try to highlight that even
these rules are simply *guidance* which may be trumped by some other
circumstance or the local conventions of code.

I'm not trying to change the thrust of this part of the document, and if
folks think this does so, I'm happy to re-wordsmith it. I just don't
want it to be so self-contradicting.

llvm-svn: 202495

for the style templates we're using.

llvm-svn: 202494

hopefully easier to get the formatting right for ReST.

llvm-svn: 202493

llvm-svn: 202490

llvm-svn: 202489

FreeBSD 10.0 and newer have a modern Clang toolchain that should work
well.

llvm-svn: 202488

a more modern host C++ toolchain for Linux distros where folks sometimes
don't have a good option to get one as part of their system.

This is a first cut, so feedback, testing, and suggestions are very,
very welcom. This is one of the last real documentation changes that was
specifically requested prior to switching LLVM and Clang to build in
C++11 mode by default.

llvm-svn: 202486

A really simple patch marks the end of a lot of yak shaving :-)

llvm-svn: 202463

seems unlikely to be added. It also doesn't seem like it should be part
of the build system at all (consider out-of-tree builds).

We should probably add nice, easy tool for this that works both for svn
client trees and git-svn client trees, but it probably won't be spelled
"make update".

llvm-svn: 202430

toolchain of LLVM. These are already being enforced by the build system
and have been discussed quite a few times on the lists, but
documentation is important. =]

Also, garbage collect the majority of the information about broken host
GCC toolchains. These aren't really relevant any more as they're all
older than the minimum requirement. I've left a few notes about
compilers one step older than the current requirement as these compilers
are at least conceivable to use, and it's better to preserve this kind
of hard-won institutional knowledge.

The next step will be some specific docs on how to set up a sufficiently
modern host toolchain if your system doesn't come with one. But that'll
be tomorrow. =]

llvm-svn: 202375

bits of software and to use a modern GCC version.

The Subversion bit was weird anyways -- it has nothing to do with
compiling LLVM. Also, there are many other ways to get at the trunk
source (git, git-svn, etc).

The TeXinfo thing... I have no idea about. But you can get a working
LLVM w/o it pretty easily. If man pages or something are missing, that
hardly seems like a problem. If folks really want this back, let me
know, but it seems mostly like a distraction.

I'd still like to separate this into:
- Required software to compile.
- Optional software to compile.
- Required software for certain *contributor* activities (like
  regenerating configure scripts).

Also we need to mention that there are multiple options for build
systems, and the differences.

Also we should mention Windows.

Also probably other stuff I'm forgetting.

I'm wondering if this whole thing needs to be shot in the head and we
should just start a new, simpler getting started that doesn't have so
many years of accumulated stuff that is no longer relevant.

llvm-svn: 202373

llvm-svn: 202372

actually looks like the table on the webpage and is entertainingly
smaller, easier to read, and easier to edit.

llvm-svn: 202371

getting started guide.

Some highlights:
- I heard there was this Clang compiler that you could use for your
  host compiler. Not sure though.
- We no longer have a GCC frontend with weird build restrictions.
- Windows is doing a bit better than partially supported.
- We nuked everything to do with itanium.
- SPUs? Really?
- Xcode 2.5 and gcc 4.0.1 are really not a concern -- they don't work.
- OMG, we actually tried building LLVM on Alpha? Really?
- PowerPC works pretty well these days.

There is still a lot of stuff here I'm pretty dubious about, but I nuked
most of what was actively misleading, out of date, or patently wrong.
Some of it (mingw stuff especially) isn't really lacking, its just that
the comments here were actively wrong. Hopefully folks that know those
platforms can add back correct / modern information.

llvm-svn: 202370

llvm-svn: 202354

The original text is very terse, so I've expanded on it.

Specifically, in the original text:

 * "The selector value is a positive number if the exception matched a
   type info" -- It wasn't clear that this meant "if the exception
   matched a 'catch' clause".

 * "If nothing is matched, the behavior of the program is
   `undefined`_."  -- It's actually implementation-defined in C++
   rather than undefined, as the new text explains.

llvm-svn: 202209

This replaces the old NoIntegratedAssembler with at TargetOption. This is
more flexible and will be used to forward clang's -no-integrated-as option.

llvm-svn: 201836

output) when the integrated assembler is enabled.

llvm-svn: 201770

Some references to llvm-gcc were so crusty that I wasn't sure how to
proceed and so I've left them intact.

I also slipped in a quick peephole fix to use a :doc: link instead of
raw HTML link.

llvm-svn: 201619

From a cursory look it seems like all the described commandline options
and such apply to clang just fine, but I'd appreciate a second opinion.

llvm-svn: 201616

Introducing llvm-profdata, a tool for merging profile data generated by
PGO instrumentation in clang.

- The name indicates a file extension of <name>.profdata.  Eventually
  profile data output by clang should be changed to that extension.

- llvm-profdata merges two profiles.  However, the name is more general,
  since it will likely pick up more tasks (such as summarizing a single
  profile).

- llvm-profdata parses the current text-based format, but will be
  updated once we settle on a binary format.

<rdar://problem/15949645>

llvm-svn: 201535

llvm-svn: 201464

llvm-svn: 201461

I noticed this convention from the commit logs.  It seems like it
would be useful to document it, to encourage other committers to link
back to code reviews in their commits.

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

llvm-svn: 201160

Fun fact: looking at the TableGen code (around TGParser.cpp:1166), the
only difference in handling is that adjacent regular string literals are
concatenated in the parser.

llvm-svn: 201035

Code fragments are just fancy string literals.

llvm-svn: 201034

They're called code fragments, but they are really multiline string
literals. Just spotted this usage in a patch by Aaron using "code
fragments" for holding documentation text. I remember someone bemoaning
the lack of multiline string literals in TableGen, so I'm explicitly
documenting that code fragments are multiline string literals.

Let it be known that any use case needing multiline string literals in
TableGen (such as descriptions of options, or whatnot) can use use
code fragments (instead of C-style string concatenation or exceedingly
long lines). E.g.

    class Bar<int n>;
    class Baz<int n>;
    class Doc<string desc> {
        string Desc = desc;
    }
    def Foo : Bar<1>, Baz<3>, Doc<[{
    This Foo is a Bar, and also a Baz. It can take 3 values:
        * Qux
        * Quux
        * Quuux
    }]>;

llvm-svn: 201033

Clang itself was not using this. The only way to access it was via llc.

llvm-svn: 200862

Based on the following discussion:
http://llvm.1065342.n5.nabble.com/LLVM-3-4-stable-releases-td65005.html

llvm-svn: 200772

llvm-svn: 200758

llvm-svn: 200699

LowerExpectIntrinsic previously only understood the idiom of an expect
intrinsic followed by a comparison with zero. For llvm.expect.i1, the
comparison would be stripped by the early-cse pass.

Patch by Daniel Micay.

llvm-svn: 200664

This changes the PrologueEpilogInserter and LocalStackSlotAllocation passes to
follow the extended stack layout rules for sspstrong and sspreq.

The sspstrong layout rules are:
 1. Large arrays and structures containing large arrays (>= ssp-buffer-size)
are closest to the stack protector.
 2. Small arrays and structures containing small arrays (< ssp-buffer-size) are
2nd closest to the protector.
 3. Variables that have had their address taken are 3rd closest to the
protector.


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

llvm-svn: 200601

Calls with inalloca are lowered by skipping all stores for arguments
passed in memory and the initial stack adjustment to allocate argument
memory.

Now the frontend is responsible for the memory layout, and the backend
doesn't have to do any work.  As a result these changes are pretty
minimal.

Reviewers: echristo

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

llvm-svn: 200596

MSVC always places the 'this' parameter for a method first.  The
implicit 'sret' pointer for methods always comes second.  We already
implement this for __thiscall by putting sret parameters on the stack,
but __cdecl methods require putting both parameters on the stack in
opposite order.

Using a special calling convention allows frontends to keep the sret
parameter first, which avoids breaking lots of assumptions in LLVM and
Clang.

Fixes PR15768 with the corresponding change in Clang.

Reviewers: ributzka, majnemer

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

llvm-svn: 200561

This doesn't set errno, so this should be OK.
Also update the documentation to explicitly state
that errno are not set.

llvm-svn: 200501