summaryrefslogtreecommitdiff
path: root/docs
Commit message (Collapse)AuthorAge
* Add more whitespace to fix more bullets.Richard Smith2014-02-28
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202538 91177308-0d34-0410-b5e6-96231b3b80d8
* Add whitespace to try to fix bulleted list.Richard Smith2014-02-28
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202537 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix some links to C++11 feature papers in the Coding StandardsBen Langmuir2014-02-28
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202532 91177308-0d34-0410-b5e6-96231b3b80d8
* add missing 3.4 releaseGabor Greif2014-02-28
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202531 91177308-0d34-0410-b5e6-96231b3b80d8
* [docs] Add a section to the coding standards about languages and such.Chandler Carruth2014-02-28
| | | | | | | | | | | | | | | | 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. =] git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202497 91177308-0d34-0410-b5e6-96231b3b80d8
* [docs] A slight tweak to the intro for the golden rule in the codingChandler Carruth2014-02-28
| | | | | | | | | | | | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202495 91177308-0d34-0410-b5e6-96231b3b80d8
* [docs] Tweak the example to match what is apparantly the desired formChandler Carruth2014-02-28
| | | | | | for the style templates we're using. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202494 91177308-0d34-0410-b5e6-96231b3b80d8
* [docs] Switch to external hyperlink references. Much more readable andChandler Carruth2014-02-28
| | | | | | hopefully easier to get the formatting right for ReST. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202493 91177308-0d34-0410-b5e6-96231b3b80d8
* [docs] Fix my links to use the correct ReST syntax.Chandler Carruth2014-02-28
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202490 91177308-0d34-0410-b5e6-96231b3b80d8
* [docs] Fix 80-column wrap that I messed up.Chandler Carruth2014-02-28
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202489 91177308-0d34-0410-b5e6-96231b3b80d8
* [docs] Tweak discussion of BSDs based on feedback from Roman Divacky.Chandler Carruth2014-02-28
| | | | | | | FreeBSD 10.0 and newer have a modern Clang toolchain that should work well. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202488 91177308-0d34-0410-b5e6-96231b3b80d8
* [docs] Add a big section with details about how to go about acquiringChandler Carruth2014-02-28
| | | | | | | | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202486 91177308-0d34-0410-b5e6-96231b3b80d8
* Now that it is possible, use the mangler in IRObjectFile.Rafael Espindola2014-02-28
| | | | | | A really simple patch marks the end of a lot of yak shaving :-) git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202463 91177308-0d34-0410-b5e6-96231b3b80d8
* [docs] Stop advertising 'make update'. It isn't implemented in CMake andChandler Carruth2014-02-27
| | | | | | | | | | | 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". git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202430 91177308-0d34-0410-b5e6-96231b3b80d8
* [docs] Actually spell out the new version requirements for the host C++Chandler Carruth2014-02-27
| | | | | | | | | | | | | | | | | | | 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. =] git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202375 91177308-0d34-0410-b5e6-96231b3b80d8
* [docs] Clean up some of the required software to not mention irrelevantChandler Carruth2014-02-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202373 91177308-0d34-0410-b5e6-96231b3b80d8
* [docs] Switch this table to the simple form as well. No content changed.Chandler Carruth2014-02-27
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202372 91177308-0d34-0410-b5e6-96231b3b80d8
* [docs] Switch to the incredibly simpler "simple table" form. It nowChandler Carruth2014-02-27
| | | | | | | actually looks like the table on the webpage and is entertainingly smaller, easier to read, and easier to edit. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202371 91177308-0d34-0410-b5e6-96231b3b80d8
* [docs] Delete tons of bad information in the requirements section of theChandler Carruth2014-02-27
| | | | | | | | | | | | | | | | | | | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202370 91177308-0d34-0410-b5e6-96231b3b80d8
* Exception handling docs: Fix a typoMark Seaborn2014-02-27
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202354 91177308-0d34-0410-b5e6-96231b3b80d8
* Exception handling docs: Describe landingpad clauses' meanings in more detailMark Seaborn2014-02-25
| | | | | | | | | | | | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202209 91177308-0d34-0410-b5e6-96231b3b80d8
* Make DisableIntegratedAS a TargetOption.Rafael Espindola2014-02-21
| | | | | | | This replaces the old NoIntegratedAssembler with at TargetOption. This is more flexible and will be used to forward clang's -no-integrated-as option. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201836 91177308-0d34-0410-b5e6-96231b3b80d8
* Added release note about making all inline assembly parsed (even for assemblyDaniel Sanders2014-02-20
| | | | | | | output) when the integrated assembler is enabled. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201770 91177308-0d34-0410-b5e6-96231b3b80d8
* [docs] Clean up some more llvm-gcc stuffSean Silva2014-02-19
| | | | | | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201619 91177308-0d34-0410-b5e6-96231b3b80d8
* [docs] Nuke some references to llvm-gccSean Silva2014-02-18
| | | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201616 91177308-0d34-0410-b5e6-96231b3b80d8
* PGO: llvm-profdata: tool for merging profilesDuncan P. N. Exon Smith2014-02-17
| | | | | | | | | | | | | | | | | | | 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> git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201535 91177308-0d34-0410-b5e6-96231b3b80d8
* Cleanup docs about lit substitutionsNico Rieck2014-02-15
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201464 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix typoNico Rieck2014-02-15
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201461 91177308-0d34-0410-b5e6-96231b3b80d8
* Add a note about using "Differential Revision:" in commit messagesMark Seaborn2014-02-11
| | | | | | | | | | 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 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201160 91177308-0d34-0410-b5e6-96231b3b80d8
* [docs] [tblgen] clarify that code fragments are just string literalsSean Silva2014-02-09
| | | | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201035 91177308-0d34-0410-b5e6-96231b3b80d8
* [docs] [tblgen] There is no "code" type.Sean Silva2014-02-09
| | | | | | Code fragments are just fancy string literals. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201034 91177308-0d34-0410-b5e6-96231b3b80d8
* [docs] TableGen easter egg: Multiline string literalsSean Silva2014-02-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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 }]>; git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201033 91177308-0d34-0410-b5e6-96231b3b80d8
* Remove support for not using .loc directives.Rafael Espindola2014-02-05
| | | | | | Clang itself was not using this. The only way to access it was via llc. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200862 91177308-0d34-0410-b5e6-96231b3b80d8
* HowToReleaseLLVM: Add information about dot releasesTom Stellard2014-02-04
| | | | | | | Based on the following discussion: http://llvm.1065342.n5.nabble.com/LLVM-3-4-stable-releases-td65005.html git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200772 91177308-0d34-0410-b5e6-96231b3b80d8
* Add a note to documentation that Clang + libstdc++ 4.7.2 can not be used to ↵Dmitri Gribenko2014-02-04
| | | | | | build LLD. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200758 91177308-0d34-0410-b5e6-96231b3b80d8
* Add a note about Clang+LLVM on Sparc64.Venkatraman Govindaraju2014-02-03
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200699 91177308-0d34-0410-b5e6-96231b3b80d8
* Lower llvm.expect intrinsic correctly for i1Duncan P. N. Exon Smith2014-02-02
| | | | | | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200664 91177308-0d34-0410-b5e6-96231b3b80d8
* [stackprotector] Implement the sspstrong rules for stack layout.Josh Magee2014-02-01
| | | | | | | | | | | | | | | | | | | 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 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200601 91177308-0d34-0410-b5e6-96231b3b80d8
* Implement inalloca codegen for x86 with the new inalloca designReid Kleckner2014-01-31
| | | | | | | | | | | | | | | | 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 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200596 91177308-0d34-0410-b5e6-96231b3b80d8
* [ms-cxxabi] Add a new calling convention that swaps 'this' and 'sret'Reid Kleckner2014-01-31
| | | | | | | | | | | | | | | | | | | | 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 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200561 91177308-0d34-0410-b5e6-96231b3b80d8
* Allow speculating llvm.sqrt, fma and fmuladdMatt Arsenault2014-01-31
| | | | | | | | This doesn't set errno, so this should be OK. Also update the documentation to explicitly state that errno are not set. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200501 91177308-0d34-0410-b5e6-96231b3b80d8
* [Stackmaps] Record the stack size of each function that contains a ↵Juergen Ributzka2014-01-30
| | | | | | | | | | stackmap/patchpoint intrinsic. Re-applying the patch, but this time without using AsmPrinter methods. Reviewed by Andy git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200481 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert "[Stackmaps] Record the stack size of each function that contains a ↵Juergen Ributzka2014-01-30
| | | | | | | | stackmap/patchpoint intrinsic." This reverts commit r200444 to unbreak buildbots. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200445 91177308-0d34-0410-b5e6-96231b3b80d8
* [Stackmaps] Record the stack size of each function that contains a ↵Juergen Ributzka2014-01-30
| | | | | | | | stackmap/patchpoint intrinsic. Reviewed by Andy git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200444 91177308-0d34-0410-b5e6-96231b3b80d8
* Extend the preserve_most/all calling convention description in LangRef about theJuergen Ributzka2014-01-30
| | | | | | fact that the argument registers will be preserved too. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200441 91177308-0d34-0410-b5e6-96231b3b80d8
* Document EHABI enabled by defaultRenato Golin2014-01-29
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200390 91177308-0d34-0410-b5e6-96231b3b80d8
* Updating the getting started guide for Visual Studio a smidge.Aaron Ballman2014-01-23
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199934 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert my commit in r199620 that added sections about namespaces to theChandler Carruth2014-01-20
| | | | | | | | | | | | | | | | | | coding standards, and instead fix the existing section. Thanks to Daniel Jasper for pointing out we already had a section devoted to this topic. Instead of adding sections, just hack on this section some. Also fix the example in the anonymous namespace section below it to agree with the new advice. As a re-cap, this switches the LLVM preferred style to never indent namespaces. Having two approaches just led to endless (and utterly pointless) debates about what was "small enough". This wasn't helping anyone. The no-indent rule is easy to understand and doesn't really make anything harder to read. Moreover, with tools like clang-format it is considerably nicer to have simple consistent rules. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199637 91177308-0d34-0410-b5e6-96231b3b80d8
* Add some wording to the coding standards to say how to indent namespacesChandler Carruth2014-01-20
| | | | | | | | | | | (and to mention namespace ending comments). This is based on a quick discussion on the developer mailing list where there was essentially no objections to a simple and consistent rule. This should avoid future debates about whether or not a namespace is "big enough" to indent. It also matches clang-format's current behavior with LLVM source code which hasn't really seen any opposition in code reviews that I spot checked. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199620 91177308-0d34-0410-b5e6-96231b3b80d8
* Add an inalloca flag to allocasReid Kleckner2014-01-17
| | | | | | | | | | | | | | | | Summary: The only current use of this flag is to mark the alloca as dynamic, even if its in the entry block. The stack adjustment for the alloca can never be folded into the prologue because the call may clear it and it has to be allocated at the top of the stack. Reviewers: majnemer CC: llvm-commits Differential Revision: http://llvm-reviews.chandlerc.com/D2571 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199525 91177308-0d34-0410-b5e6-96231b3b80d8
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-23 06:13:18 +0000