Commit Graph

74 Commits

Author SHA1 Message Date
Simon Atanasyan 77b3c794e3 [docs] Update Mips feature table in CodeGenerator.rst
Patch by Miloš Stojanović

Differential Revision: https://reviews.llvm.org/D69381
2019-10-25 12:17:34 +03:00
Reid Kleckner f9b67b810e [X86] Add new calling convention that guarantees tail call optimization
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
2019-10-07 22:28:58 +00:00
Matt Arsenault e56a2ad85e CodeGen: Allow virtual registers in bundles
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
2019-08-01 18:41:28 +00:00
Thomas Lively e0a9dce543 [WebAssembly] Do not emit tail calls with return type mismatch
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
2019-07-30 18:08:39 +00:00
Francis Visoiu Mistrih daf801bb11 [docs][Remarks] Add documentation for remarks in LLVM
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
2019-07-09 23:16:59 +00:00
Thomas Lively a1d97a960e [WebAssembly] Implement tail calls and unify tablegen call classes
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
2019-06-26 16:17:15 +00:00
Sanjay Patel 587d4b0620 [Docs] fix formatting for bullet list; NFC
llvm-svn: 361341
2019-05-22 00:48:47 +00:00
Sanjay Patel 6a554188aa [InstCombine] fold shuffles of insert_subvectors
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
2019-05-22 00:32:25 +00:00
Yonghong Song 33434d5f04 [Docs][CodeGenerator][eBPF] Correct the values for BPF_X and BPF_K
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
2019-05-03 16:40:16 +00:00
Francis Visoiu Mistrih 465415f1db [Remarks] Fix documentation indentation
Fix the documentation bot:

http://lab.llvm.org:8011/builders/llvm-sphinx-docs/builds/30450/steps/docs-llvm-html/logs/stdio

llvm-svn: 359053
2019-04-24 00:27:59 +00:00
Francis Visoiu Mistrih 7fee2b89fd [Remarks] Add string deduplication using a string table
* 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
2019-04-24 00:06:24 +00:00
Francis Visoiu Mistrih ee1a6e70fa [Remarks] Emit a section containing remark diagnostics metadata
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
2019-03-27 01:13:59 +00:00
Hiroshi Inoue c36a1f1cb7 [NFC] fix trivial typos in documents
llvm-svn: 334799
2018-06-15 05:10:09 +00:00
Craig Topper 02a114aab4 [Docs] Remove some WIP X86 documentation I accidentally leaked into r328031.
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
2018-03-21 17:32:57 +00:00
Craig Topper b5ed275025 [TableGen] Pass result of std::unique to vector::erase instead of calculating a size and calling resize.
llvm-svn: 328031
2018-03-20 20:24:10 +00:00
Sean Eveson 2ae6037dd1 [MC] Fix -stack-size-section on ARM
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
2018-01-17 09:01:29 +00:00
Sean Eveson a6bcd53d52 [MC] Function stack size section.
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
2017-11-30 13:05:14 +00:00
Sean Eveson 661e4fbf83 Revert r319423: [MC] Function stack size section.
I messed up the diff.

llvm-svn: 319429
2017-11-30 12:43:25 +00:00
Sean Eveson f77b4d2f38 [MC] Function stack size section.
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
2017-11-30 12:01:16 +00:00
Tony Tye f16a45ea15 Add documentation for various aspects of the AMDGPU backend.
Differential Revision: https://reviews.llvm.org/D33736

llvm-svn: 304831
2017-06-06 20:31:59 +00:00
Jonathan Roelofs ebba0507da [docs] Fix typo
llvm-svn: 294645
2017-02-09 23:02:37 +00:00
Konstantin Zhuravlyov ee68fdadfe [Support/ELF/AMDGPU] Add 32-bit lo/hi got and pc relative relocations
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
2016-10-14 04:03:49 +00:00
Sylvestre Ledru 843b7515ae Fix some typos in the doc
llvm-svn: 279943
2016-08-28 20:29:18 +00:00
Renato Golin 124f2593fc [docs] Fixing Sphinx warnings to unclog the buildbot
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
2016-07-20 12:16:38 +00:00
Krzysztof Parzyszek 3da1078a9b [Docs][CodeGenerator] Don't specify the number of operands in BuildMI
Patch by Visoiu Mistrih Francis.

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

llvm-svn: 274128
2016-06-29 14:14:59 +00:00
Tom Stellard 14416ae6cd Support/ELF: Add R_AMDGPU_GOTPCREL relocation
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
2016-06-23 23:11:29 +00:00
Konstantin Zhuravlyov 4ecab84364 [docs] Update AMDGPU relocation information
- 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
2016-06-14 17:20:29 +00:00
Tom Stellard 9fdfa518eb docs: Add AMDGPU relocation information
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
2016-06-10 00:31:13 +00:00
James Y Knight 0c145c0c3a Remove bit-rotten CppBackend.
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
2016-05-05 14:35:40 +00:00
David L Kreitzer c9fbf1018a Add an address space for the X86 SS segment.
Patch by Michael LeMay (michael.lemay@intel.com)

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

llvm-svn: 268431
2016-05-03 20:16:08 +00:00
Justin Lebar ca35b090f8 [docs] "Straightforward" is one word.
llvm-svn: 263480
2016-03-14 20:18:51 +00:00
Justin Lebar 20adbdd2c0 [docs] Fix typo in docs/CodeGenerator.rst.
llvm-svn: 263479
2016-03-14 20:17:08 +00:00
Artyom Skrobov 48aee7c65b Fixing a typo in docs/CodeGenerator.rst
llvm-svn: 253045
2015-11-13 15:14:04 +00:00
Alexei Starovoitov cb6b408da4 [bpf] add documentation and instruction set description
llvm-svn: 245105
2015-08-14 22:00:45 +00:00
Charlie Turner 5b41ea0d56 [NFC] Minor editorial fixes to the CodeGen docs.
llvm-svn: 241249
2015-07-02 09:32:01 +00:00
Eric Christopher 1e61ffddc7 Fix grammar in documentation.
Patch by Ralph Campbell!

llvm-svn: 229884
2015-02-19 18:46:25 +00:00
Mehdi Amini d8976b8ed3 SelectionDAG: add a -filter-view-dags option to llc
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
2015-01-14 06:03:18 +00:00
Dan Liew 4773d0b4bf [sphinx cleanup]
Fix sphinx warning introduced by r217537

llvm-svn: 217541
2014-09-10 20:43:03 +00:00
Nico Weber 4b916b21b4 Fix docs reference to inexistent class.
Patch sent via telegraph by TNorthover. Thanks!

llvm-svn: 217537
2014-09-10 19:50:55 +00:00
Matt Arsenault 907e64b436 Add note to documentation about machine node chains.
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
2014-09-02 19:18:52 +00:00
Sean Silva 9ab8899f5c [docs] Fix a mangled sentence.
Fixes PR20169

llvm-svn: 212116
2014-07-01 18:22:32 +00:00
Sean Silva ff6a7d6d32 [docs] Remove stray HTML tag.
Fixes PR20167

llvm-svn: 212115
2014-07-01 18:15:00 +00:00
Alp Toker cf21875d41 Fix 'platform-specific' hyphenations
llvm-svn: 212056
2014-06-30 18:57:16 +00:00
Jay Foad 5ace2cd512 Fix strange typo in markup.
llvm-svn: 208759
2014-05-14 08:10:16 +00:00
Reid Kleckner c487d73f41 Revert "[ms-cxxabi] Add a new calling convention that swaps 'this' and 'sret'"
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
2014-05-09 22:56:42 +00:00
Sean Silva 1703e705cf [docs] Fix up some links to the preferred style.
: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
2014-04-08 21:06:22 +00:00
Sean Silva 397ee6ec98 [docs] Fix some links
The TableGen docs have changed structure

Patch by Tay Ray Chuan!

llvm-svn: 205744
2014-04-07 22:46:40 +00:00
Reid Kleckner 1c843228f8 [ms-cxxabi] Add a new calling convention that swaps 'this' and 'sret'
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
2014-01-31 17:41:22 +00:00
Tim Northover cdc5395680 Docs: fix sign of division and increase equivocation on code generated.
I should have been a politician.

llvm-svn: 199092
2014-01-13 10:47:04 +00:00
Rafael Espindola b665d79f14 Add more documentation about the TargetStreamer interface.
llvm-svn: 192796
2013-10-16 14:54:39 +00:00