RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-12-19 09:36:44 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Some sphinx-ing and consistency fixes

Browse Source 
llvm-svn: 168380
This commit is contained in:
Eli Bendersky 2012-11-20 19:37:58 +00:00
parent 760b5f1eb8
commit 5d1da4526f
1 changed files with 15 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

31
docs/TableGenFundamentals.rst
View File

@ -120,16 +120,16 @@ this (at the time of this writing):
}
...
This definition corresponds to a 32-bit register-register add instruction in the
X86. The string after the '``def``' string indicates the name of the
record---"``ADD32rr``" in this case---and the comment at the end of the line
indicates the superclasses of the definition. The body of the record contains
all of the data that TableGen assembled for the record, indicating that the
instruction is part of the "X86" namespace, the pattern indicating how the the
instruction should be emitted into the assembly file, that it is a two-address
instruction, has a particular encoding, etc. The contents and semantics of the
information in the record is specific to the needs of the X86 backend, and is
only shown as an example.
This definition corresponds to the 32-bit register-register ``add`` instruction
of the the x86 architecture. ``def ADD32rr`` defines a record named
``ADD32rr``, and the comment at the end of the line indicates the superclasses
of the definition. The body of the record contains all of the data that
TableGen assembled for the record, indicating that the instruction is part of
the "X86" namespace, the pattern indicating how the the instruction should be
emitted into the assembly file, that it is a two-address instruction, has a
particular encoding, etc. The contents and semantics of the information in the
record are specific to the needs of the X86 backend, and are only shown as an
example.
As you can see, a lot of information is needed for every instruction supported
by the code generator, and specifying it all manually would be unmaintainable,
@ -152,13 +152,12 @@ factor out the common features that instructions of its class share. A key
feature of TableGen is that it allows the end-user to define the abstractions
they prefer to use when describing their information.
Each def record has a special entry called "``NAME``." This is the name of the
def ("``ADD32rr``" above). In the general case def names can be formed from
various kinds of string processing expressions and ``NAME`` resolves to the
Each ``def`` record has a special entry called "NAME". This is the name of the
record ("``ADD32rr``" above). In the general case ``def`` names can be formed
from various kinds of string processing expressions and ``NAME`` resolves to the
final value obtained after resolving all of those expressions. The user may
refer to ``NAME`` anywhere she desires to use the ultimate name of the def.
``NAME`` should not be defined anywhere else in user code to avoid conflict
problems.
refer to ``NAME`` anywhere she desires to use the ultimate name of the ``def``.
``NAME`` should not be defined anywhere else in user code to avoid conflicts.
Running TableGen
----------------