summaryrefslogtreecommitdiffstats
path: root/llvm/docs/CodeGenerator.rst
Commit message (Collapse)AuthorAgeFilesLines
* [Docs] Fix target feature matrix for PowerPC and SystemZKai Nacke2019-12-131-4/+4
| | | | | | | | | | | | | | The target feature matrix in the code generator documentation is outdated. This PR fixes some entries for PowerPC and SystemZ. Both have: - assembly parser - disassembler - .o file writing Reviewers: uweigand Differential Revision: https://reviews.llvm.org/D71004
* [docs] Update Mips feature table in CodeGenerator.rstSimon Atanasyan2019-10-251-5/+5
| | | | | | Patch by Miloš Stojanović Differential Revision: https://reviews.llvm.org/D69381
* [X86] Add new calling convention that guarantees tail call optimizationReid Kleckner2019-10-071-2/+2
| | | | | | | | | | | | | | | | | When the target option GuaranteedTailCallOpt is specified, calls with the fastcc calling convention will be transformed into tail calls if they are in tail position. This diff adds a new calling convention, tailcc, currently supported only on X86, which behaves the same way as fastcc, except that the GuaranteedTailCallOpt flag does not need to enabled in order to enable tail call optimization. Patch by Dwight Guth <dwight.guth@runtimeverification.com>! Reviewed By: lebedev.ri, paquette, rnk Differential Revision: https://reviews.llvm.org/D67855 llvm-svn: 373976
* CodeGen: Allow virtual registers in bundlesMatt Arsenault2019-08-011-9/+12
| | | | | | | | | | | | | | | The note in the documentation suggests this restriction is a compile time optimization for architectures that make heavy use of bundling. Allowing virtual registers in a bundle is useful for some (non-R600) AMDGPU use cases and are infrequent enough to matter. A more common AMDGPU use case has already been using virtual registers in bundles since r333691, although never calling finalizeBundle on them and manually creating the use/def list on the BUNDLE instruction. This is also relatively infrequent, and only happens for consecutive sequences of some load/store types. llvm-svn: 367597
* [WebAssembly] Do not emit tail calls with return type mismatchThomas Lively2019-07-301-3/+8
| | | | | | | | | | | | | | | | | Summary: return_call and return_call_indirect are only valid if the return types of the callee and caller match. We were previously not enforcing that, which was producing invalid modules. Reviewers: aheejin Subscribers: dschuff, sbc100, jgravelle-google, hiraditya, sunfish, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D65246 llvm-svn: 367339
* [docs][Remarks] Add documentation for remarks in LLVMFrancis Visoiu Mistrih2019-07-091-14/+0
| | | | | | | | | | | | | | | This adds documentation that describes remarks in LLVM. It aims at explaining what remarks are, how to enable them, and what users can do with the different modes. It lists all the available flags in LLVM (excluding clang), and describes the expected YAML structure as well as the tools that support the YAML format today. Differential Revision: https://reviews.llvm.org/D64355 llvm-svn: 365578
* [WebAssembly] Implement tail calls and unify tablegen call classesThomas Lively2019-06-261-1/+6
| | | | | | | | | | | | | | | | | Summary: Implements direct and indirect tail calls enabled by the 'tail-call' feature in both DAG ISel and FastISel. Updates existing call tests and adds new tests including a binary encoding test. Reviewers: aheejin Subscribers: dschuff, sbc100, jgravelle-google, hiraditya, sunfish, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D62877 llvm-svn: 364445
* [Docs] fix formatting for bullet list; NFCSanjay Patel2019-05-221-11/+11
| | | | llvm-svn: 361341
* [InstCombine] fold shuffles of insert_subvectorsSanjay Patel2019-05-221-0/+25
| | | | | | | | | | | | | | | | | This should be a valid exception to the general rule of not creating new shuffle masks in IR... because we already do it. :) Also, DAG combining/legalization will undo this by widening the shuffle back out if needed. Explanation for how we already do this: SLP or vector source can create chains of insert/extract as shown in 1 of the examples from PR16739: https://godbolt.org/z/NlK7rA https://bugs.llvm.org/show_bug.cgi?id=16739 And we expect instcombine or DAGCombine to clean that up by creating relatively simple shuffles. Differential Revision: https://reviews.llvm.org/D62024 llvm-svn: 361338
* [Docs][CodeGenerator][eBPF] Correct the values for BPF_X and BPF_KYonghong Song2019-05-031-2/+2
| | | | | | | | | | | | | | | | Fix the values of BPF_X and BPF_K according to BPFInstrFormats.td: " def BPF_K : BPFSrcType<0x0>; def BPF_X : BPFSrcType<0x1>; " The right value for BPF_X is 0x1, and the right value for BPF_K is 0x0. Signed-off-by: Wang YanQing <udknight@gmail.com> Differential Revision: https://reviews.llvm.org/D61512 llvm-svn: 359904
* [Remarks] Fix documentation indentationFrancis Visoiu Mistrih2019-04-241-5/+4
| | | | | | | | Fix the documentation bot: http://lab.llvm.org:8011/builders/llvm-sphinx-docs/builds/30450/steps/docs-llvm-html/logs/stdio llvm-svn: 359053
* [Remarks] Add string deduplication using a string tableFrancis Visoiu Mistrih2019-04-241-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * Add support for uniquing strings in the remark streamer and emitting the string table in the remarks section. * Add parsing support for the string table in the RemarkParser. From this remark: ``` --- !Missed Pass: inline Name: NoDefinition DebugLoc: { File: 'test-suite/SingleSource/UnitTests/2002-04-17-PrintfChar.c', Line: 7, Column: 3 } Function: printArgsNoRet Args: - Callee: printf - String: ' will not be inlined into ' - Caller: printArgsNoRet DebugLoc: { File: 'test-suite/SingleSource/UnitTests/2002-04-17-PrintfChar.c', Line: 6, Column: 0 } - String: ' because its definition is unavailable' ... ``` to: ``` --- !Missed Pass: 0 Name: 1 DebugLoc: { File: 3, Line: 7, Column: 3 } Function: 2 Args: - Callee: 4 - String: 5 - Caller: 2 DebugLoc: { File: 3, Line: 6, Column: 0 } - String: 6 ... ``` And the string table in the .remarks/__remarks section containing: ``` inline\0NoDefinition\0printArgsNoRet\0 test-suite/SingleSource/UnitTests/2002-04-17-PrintfChar.c\0printf\0 will not be inlined into \0 because its definition is unavailable\0 ``` This is mostly supposed to be used for testing purposes, but it gives us a 2x reduction in the remark size, and is an incremental change for the updates to the remarks file format. Differential Revision: https://reviews.llvm.org/D60227 llvm-svn: 359050
* [Remarks] Emit a section containing remark diagnostics metadataFrancis Visoiu Mistrih2019-03-271-0/+11
| | | | | | | | | | | | | | | | A section containing metadata on remark diagnostics will be emitted if the flag (-mllvm) -remarks-section is present. For now, the metadata is: * a magic number for remarks: "REMARKS\0" * the version number: a little-endian uint64_t * the absolute file path to the serialized remark diagnostics: a null-terminated string. Differential Revision: https://reviews.llvm.org/D59571 llvm-svn: 357043
* [NFC] fix trivial typos in documentsHiroshi Inoue2018-06-151-1/+1
| | | | llvm-svn: 334799
* [Docs] Remove some WIP X86 documentation I accidentally leaked into r328031.Craig Topper2018-03-211-6/+0
| | | | | | I didn't mean to commit it, but I guess I failed to switch branches or stash it in my local tree. llvm-svn: 328124
* [TableGen] Pass result of std::unique to vector::erase instead of ↵Craig Topper2018-03-201-0/+6
| | | | | | calculating a size and calling resize. llvm-svn: 328031
* [MC] Fix -stack-size-section on ARMSean Eveson2018-01-171-1/+1
| | | | | | | | Change symbol values in the stack_size section from being 8 bytes, to being a target dependent size. Differential Revision: https://reviews.llvm.org/D42108 llvm-svn: 322619
* [MC] Function stack size section.Sean Eveson2017-11-301-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | Re applying after fixing issues in the diff, sorry for any painful conflicts/merges! Original RFC: http://lists.llvm.org/pipermail/llvm-dev/2017-August/117028.html This change adds a '.stack-size' section containing metadata on function stack sizes to output ELF files behind the new -stack-size-section flag. The section contains pairs of function symbol references (8 byte) and stack sizes (unsigned LEB128). The contents of this section can be used to measure changes to stack sizes between different versions of the compiler or a source base. The advantage of having a section is that we can extract this information when examining binaries that we didn't build, and it allows users and tools easy access to that information just by referencing the binary. There is a follow up change to add an option to clang. Thanks. Reviewers: hfinkel, MatzeB Reviewed By: MatzeB Subscribers: thegameg, asb, llvm-commits Differential Revision: https://reviews.llvm.org/D39788 llvm-svn: 319430
* Revert r319423: [MC] Function stack size section.Sean Eveson2017-11-301-2658/+2647
| | | | | | I messed up the diff. llvm-svn: 319429
* [MC] Function stack size section.Sean Eveson2017-11-301-2647/+2658
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Original RFC: http://lists.llvm.org/pipermail/llvm-dev/2017-August/117028.html I wasn't sure who to put as reviewers, so please add/remove people as appropriate. This change adds a '.stack-size' section containing metadata on function stack sizes to output ELF files behind the new -stack-size-section flag. The section contains pairs of function symbol references (8 byte) and stack sizes (unsigned LEB128). The contents of this section can be used to measure changes to stack sizes between different versions of the compiler or a source base. The advantage of having a section is that we can extract this information when examining binaries that we didn't build, and it allows users and tools easy access to that information just by referencing the binary. There is a follow up change to add an option to clang. Thanks. Reviewers: hfinkel, MatzeB Reviewed By: MatzeB Subscribers: thegameg, asb, llvm-commits Differential Revision: https://reviews.llvm.org/D39788 llvm-svn: 319423
* Add documentation for various aspects of the AMDGPU backend.Tony Tye2017-06-061-56/+3
| | | | | | Differential Revision: https://reviews.llvm.org/D33736 llvm-svn: 304831
* [docs] Fix typoJonathan Roelofs2017-02-091-2/+2
| | | | llvm-svn: 294645
* [Support/ELF/AMDGPU] Add 32-bit lo/hi got and pc relative relocationsKonstantin Zhuravlyov2016-10-141-12/+16
| | | | | | | | | | | | | | Added relocation names: - R_AMDGPU_GOTPCREL32_LO - R_AMDGPU_GOTPCREL32_HI - R_AMDGPU_REL32_LO - R_AMDGPU_REL32_HI AMDGPU isa only supports 32-bit immediates. In order to access 64-bit address we need to generate 32-bit lo/hi relocations, and do the right math (separate patch). Currently we only generate one 32 bit relocation for lower bits for each access, losing higher bits. Hence we need relocations listed above. Differential Revision: https://reviews.llvm.org/D25546 llvm-svn: 284191
* Fix some typos in the docSylvestre Ledru2016-08-281-1/+1
| | | | llvm-svn: 279943
* [docs] Fixing Sphinx warnings to unclog the buildbotRenato Golin2016-07-201-3/+3
| | | | | | | | | | | | | | | | | | | | | | | 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
* [Docs][CodeGenerator] Don't specify the number of operands in BuildMIKrzysztof Parzyszek2016-06-291-16/+11
| | | | | | | | Patch by Visoiu Mistrih Francis. Differential Revision: http://reviews.llvm.org/D21819 llvm-svn: 274128
* Support/ELF: Add R_AMDGPU_GOTPCREL relocationTom Stellard2016-06-231-0/+4
| | | | | | | | | | | | | Summary: We will start generating this in a future patch. Reviewers: arsenm, kzhuravl, rafael, ruiu, tony-tye Subscribers: arsenm, llvm-commits, kzhuravl Differential Revision: http://reviews.llvm.org/D21482 llvm-svn: 273628
* [docs] Update AMDGPU relocation informationKonstantin Zhuravlyov2016-06-141-13/+14
| | | | | | | | | | | | | | | | | - Added new notation for specifying relocation calculation - Renamed: - R_AMDGPU_32_LOW -> R_AMDGPU_ABS32_LO - R_AMDGPU_32_HIGH -> R_AMDGPU_ABS32_HI - R_AMDGPU_64 -> R_AMDGPU_ABS64 - Added: - R_AMDGPU_REL32 - R_AMDGPU_REL64 - R_AMDGPU_ABS32 - Updated calculations for relative relocations Differential Revision: http://reviews.llvm.org/D21215 llvm-svn: 272684
* docs: Add AMDGPU relocation informationTom Stellard2016-06-101-0/+51
| | | | | | | | | | | | | | | | | | | | Summary: This documents the various relocation types that are supported by the Radeon Open Compute (ROC) runtime (which is essentially the dynamic linker for AMDGPU). Only R_AMDGPU_32 is not currently supported by the ROC runtime, but it will usually be resolved at link time by lld. Patch by: Konstantin Zhuravlyov Reviewers: kzhuravl, rafael Subscribers: rafael, arsenm, llvm-commits, kzhuravl Differential Revision: http://reviews.llvm.org/D20952 llvm-svn: 272352
* Remove bit-rotten CppBackend.James Y Knight2016-05-051-7/+5
| | | | | | | | | | | | | | | | | This backend was supposed to generate C++ code which will re-construct the LLVM IR passed as input. This seems to me to have very marginal usefulness in the first place. However, the code has never been updated to use IRBuilder, which makes its current value negative -- people who look at the output may be steered to use the *wrong* C++ APIs to construct IR. Furthermore, it's generated code that doesn't compile since at least 2013. Differential Revision: http://reviews.llvm.org/D19942 llvm-svn: 268631
* Add an address space for the X86 SS segment.David L Kreitzer2016-05-031-3/+3
| | | | | | | | Patch by Michael LeMay (michael.lemay@intel.com) Differential Revision: http://reviews.llvm.org/D17093 llvm-svn: 268431
* [docs] "Straightforward" is one word.Justin Lebar2016-03-141-1/+1
| | | | llvm-svn: 263480
* [docs] Fix typo in docs/CodeGenerator.rst.Justin Lebar2016-03-141-1/+1
| | | | llvm-svn: 263479
* Fixing a typo in docs/CodeGenerator.rstArtyom Skrobov2015-11-131-1/+1
| | | | llvm-svn: 253045
* [bpf] add documentation and instruction set descriptionAlexei Starovoitov2015-08-141-0/+197
| | | | llvm-svn: 245105
* [NFC] Minor editorial fixes to the CodeGen docs.Charlie Turner2015-07-021-2/+2
| | | | llvm-svn: 241249
* Fix grammar in documentation.Eric Christopher2015-02-191-3/+3
| | | | | | Patch by Ralph Campbell! llvm-svn: 229884
* SelectionDAG: add a -filter-view-dags option to llcMehdi Amini2015-01-141-1/+5
| | | | | | | | | This option takes the name of the basic block you want to visualize with -view-*-dags Differential Revision: http://reviews.llvm.org/D6948 llvm-svn: 225953
* [sphinx cleanup]Dan Liew2014-09-101-1/+1
| | | | | | Fix sphinx warning introduced by r217537 llvm-svn: 217541
* Fix docs reference to inexistent class.Nico Weber2014-09-101-2/+2
| | | | | | Patch sent via telegraph by TNorthover. Thanks! llvm-svn: 217537
* Add note to documentation about machine node chains.Matt Arsenault2014-09-021-1/+3
| | | | | | | | | | I've been assuming chain operands were always the first operand, since the documentation says this. I was confused about why they were missing after instruction selection. Apparently the convention changes to using the last operand for MachineSDNodes and I've never noticed before. llvm-svn: 216934
* [docs] Fix a mangled sentence.Sean Silva2014-07-011-1/+1
| | | | | | Fixes PR20169 llvm-svn: 212116
* [docs] Remove stray HTML tag.Sean Silva2014-07-011-1/+1
| | | | | | Fixes PR20167 llvm-svn: 212115
* Fix 'platform-specific' hyphenationsAlp Toker2014-06-301-1/+1
| | | | llvm-svn: 212056
* Fix strange typo in markup.Jay Foad2014-05-141-2/+2
| | | | llvm-svn: 208759
* Revert "[ms-cxxabi] Add a new calling convention that swaps 'this' and 'sret'"Reid Kleckner2014-05-091-4/+0
| | | | | | | | | | | | | | This reverts commit r200561. This calling convention was an attempt to match the MSVC C++ ABI for methods that return structures by value. This solution didn't scale, because it would have required splitting every CC available on Windows into two: one for methods and one for free functions. Now that we can put sret on the second arg (r208453), and Clang does that (r208458), revert this hack. llvm-svn: 208459
* [docs] Fix up some links to the preferred style.Sean Silva2014-04-081-1/+1
| | | | | | | | | | | | | :doc:`...` and :ref:`...` links help Sphinx keep track the dependencies between documents and ensure that they are not pointing to nowhere. Raw HTML links work just fine and are easier for people less familiar with reST/Sphinx. They are easy to change over to the :doc:/:ref: style after the fact so this is not a problem. This commit doesn't fix all of them. llvm-svn: 205792
* [docs] Fix some linksSean Silva2014-04-071-2/+2
| | | | | | | | The TableGen docs have changed structure Patch by Tay Ray Chuan! llvm-svn: 205744
* [ms-cxxabi] Add a new calling convention that swaps 'this' and 'sret'Reid Kleckner2014-01-311-0/+4
| | | | | | | | | | | | | | | | | | | | 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
* Docs: fix sign of division and increase equivocation on code generated.Tim Northover2014-01-131-5/+5
| | | | | | I should have been a politician. llvm-svn: 199092
OpenPOWER on IntegriCloud