Summary:
The RFC proposal sent to increase the minimum required GCC version
to 4.8 received a lot of support. See the following thread:
http://lists.llvm.org/pipermail/llvm-dev/2016-October/105955.html,
This patch implements that by updating the docs. I believe the
references to libstdc++ 4.7 issues can be removed as well, please
let me know if that is not the case or if they should be updated
a different way.
Reviewers: rengolin
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D25683
llvm-svn: 284497
Uses of this have all been updated to use LLVM_NODISCARD, which
matches the C++17 [[nodiscard]] semantics rather than those of GCC's
__attribute__((warn_unused_result)).
llvm-svn: 284367
Summary:
* Describe new (3.3) parameter attribute group encoding, leaving old encoding there with a note about legacy
* Bring TYPE_BLOCK docs up to date
* Remove docs about obsolete (pre 3.0) TYPE_SYMTAB_BLOCK, TST_CODE_ENTRY
* Fix a couple of incorrect comments and remove one unused enum definition along the way
This addresses https://llvm.org/bugs/show_bug.cgi?id=28941.
Patch by: Ismail Badawi <ibadawi@cisco.com>
Differential Revision: https://reviews.llvm.org/D25623
llvm-svn: 284246
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
This document describes the proposal to move to GitHub, and
compare the two proposals through various workflow examples,
presenting the current set of commands following by the ones
involved in each of the two proposals.
It is intended to supersede the previous "submodule proposal"
document entirely, and drive the discussion at the BoF during
the next Dev Meeting.
Differential Revision: https://reviews.llvm.org/D24167
llvm-svn: 284077
Summary: We need a new LLVM intrinsic to implement MS _AddressOfReturnAddress builtin on 64-bit Windows.
Reviewers: majnemer, rnk
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D25293
llvm-svn: 284061
The core of the change is supposed to be NFC, however it also fixes
what I believe was an undefined behavior when calling:
va_start(ValueArgs, Desc);
with Desc being a StringRef.
Differential Revision: https://reviews.llvm.org/D25342
llvm-svn: 283671
Summary:
The acronym PR could be ambiguous to some users, especially those who
are used to interpreting it as GitHub's "pull request".
Reviewers: ddunbar, jordan_rose, void, beanz
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D25331
llvm-svn: 283465
Support overriding the Doxygen & OCamldoc install directories,
and provide a more FHS-compliant defaults for both of them. This extends
r282240 that added this override for Sphinx-built documentation.
LLVM_INSTALL_DOXYGEN_HTML_DIR and LLVM_INSTALL_OCAMLDOC_HTML_DIR are
added, to control the location where Doxygen-generated and
OCamldoc-generated HTML docs are installed appropriately. They both
specify CMake-style install paths, and therefore can either by relative
to the install prefix or absolute.
The new defaults are subdirectories of share/doc/llvm, and replace
the previous directories of 'docs/html' and 'docs/ocaml/html' that
resulted in creating invalid '/usr/docs' that furthermore lacked proper
namespacing for the LLVM package. The new defaults are consistent with
the ones used for Sphinx HTML documentation, differing only in the last
component. Since the 'html' subdirectory is already used for Sphinx
docs, the 'doxygen-html' and 'ocaml-html' directories are used instead.
Differential Revision: https://reviews.llvm.org/D24935
llvm-svn: 282536
This patch updates WritingAnLLVMPass.rst to make it in line with current state of things.
Specifically:
* Makefile instructions replaced with CMake ones
* Filenames replaced with correct ones
* Example reformatted a bit to make it less confusing and more conforming to LLVM Coding Standards
* opt tool output updated with what it actually prints nowdays
* "gcse" (which doesn't exist anymore) replaced with "gvn" (which still does)
Differential Revision: https://reviews.llvm.org/D24233
llvm-svn: 282482
Summary:
Add links to ISA manuals and ABI.
Add text about assembler syntax.
Add info about instructions operands.
Add instruction examples for each encoding.
Update directives section, add missing .amdgpu_hsa_kernel.
Reviewers: tstellarAMD, SamWot, vpykhtin
Subscribers: kzhuravl, wdng, nhaehnle, yaxunl, tony-tye, artem.tamazov, llvm-commits
Differential Revision: https://reviews.llvm.org/D24724
llvm-svn: 281962
Summary:
It was previously not possible for tools to use solely the stackmap
information emitted to reconstruct the return addresses of callsites in
the map, which is necessary to use the information to walk a stack. This
patch adds per-function callsite counts when emitting the stackmap
section in order to resolve the problem. Note that this slightly alters
the stackmap format, so external tools parsing these maps will need to
be updated.
**Problem Details:**
Records only store their offset from the beginning of the function they
belong to. While these records and the functions are output in program
order, it is not possible to determine where the end of one function's
records are without the callsite count when processing the records to
compute return addresses.
Patch by Kavon Farvardin!
Reviewers: atrick, ributzka, sanjoy
Subscribers: nemanjai
Differential Revision: https://reviews.llvm.org/D23487
llvm-svn: 281532
On Windows, it is often applied to the second parameter, and the x86
backend is prepared to deal with sret appearing on any parameter.
Other backends assume it only appears on parameter zero, but those are
target-specific requirements, and not an IR-level rule.
llvm-svn: 280951
No need to have a long inline code snippet in this doc.
Also move "flags that control numerical code" underneath the "invoking
clang" section, and reformat things a bit.
llvm-svn: 280857
CUDA is an extension to C++ -- there is no such thing as "CUDA C". But
also, the language is much more commonly called "CUDA" than "CUDA C++".
llvm-svn: 280849
Hans Wennborg