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

llvm-svn: 279943

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

Patch by Visoiu Mistrih Francis.

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

llvm-svn: 274128

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

  - 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

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

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

Patch by Michael LeMay (michael.lemay@intel.com)

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

llvm-svn: 268431

llvm-svn: 263480

llvm-svn: 263479

llvm-svn: 253045

llvm-svn: 245105

llvm-svn: 241249

Patch by Ralph Campbell!

llvm-svn: 229884

    
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

Fix sphinx warning introduced by r217537

llvm-svn: 217541

Patch sent via telegraph by TNorthover. Thanks!

llvm-svn: 217537

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

Fixes PR20169

llvm-svn: 212116

Fixes PR20167

llvm-svn: 212115

llvm-svn: 212056

llvm-svn: 208759

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

: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

The TableGen docs have changed structure

Patch by Tay Ray Chuan!

llvm-svn: 205744

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

I should have been a politician.

llvm-svn: 199092

llvm-svn: 192796

llvm-svn: 192265

llvm-svn: 191752

Approval in here http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-July/064169.html

llvm-svn: 187145

llvm-svn: 181777

llvm-svn: 181431

Disassembler support has recently been added. Fill in some other unknowns
at the same time.

llvm-svn: 181156

of complex instruction operands (e.g. address modes).

Currently, if a Pat pattern creates an instruction that has a complex
operand (i.e. one that consists of multiple sub-operands at the MI
level), this operand must match a ComplexPattern DAG pattern with the
correct number of output operands.

This commit extends TableGen to alternatively allow match a complex
operands against multiple separate operands at the DAG level.

This allows using Pat patterns to match pre-increment nodes like
pre_store (which must have separate operands at the DAG level) onto
an instruction pattern that uses a multi-operand memory operand,
like the following example on PowerPC (will be committed as a
follow-on patch):

  def STWU  : DForm_1<37, (outs ptr_rc:$ea_res), (ins GPRC:$rS, memri:$dst),
                    "stwu $rS, $dst", LdStStoreUpd, []>,
                    RegConstraint<"$dst.reg = $ea_res">, NoEncode<"$ea_res">;

  def : Pat<(pre_store GPRC:$rS, ptr_rc:$ptrreg, iaddroff:$ptroff),
            (STWU GPRC:$rS, iaddroff:$ptroff, ptr_rc:$ptrreg)>;

Here, the pair of "ptroff" and "ptrreg" operands is matched onto the
complex operand "dst" of class "memri" in the "STWU" instruction.

Approved by Jakob Stoklund Olesen.

llvm-svn: 177428

llvm-svn: 173971

llvm-svn: 172235

Target Feature Matrix, and update the PTX column with this new category.

llvm-svn: 172234

Before we learned about :doc:, we used :ref: and put a dummy link at the
top of each page. Don't do that anymore.

This fixes PR14891 as a special case.

llvm-svn: 172162