summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorSean Silva <silvas@purdue.edu>2012-12-27 10:23:04 +0000
committerSean Silva <silvas@purdue.edu>2012-12-27 10:23:04 +0000
commitbdb0c0aaf3a9f02dd590667c9d068905e0f483fe (patch)
treeab5e43337d2c3fca59f19e70e0f90ae0266c1852
parent6fa16e192f5229fcdd61778112c524f63d20f877 (diff)
docs: Add FAQ about "storing to a virtual register".
This came up for the N+1'st time today in IRC. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171155 91177308-0d34-0410-b5e6-96231b3b80d8
-rw-r--r--docs/FAQ.rst23
1 files changed, 23 insertions, 0 deletions
diff --git a/docs/FAQ.rst b/docs/FAQ.rst
index 67e8d0b27b..b4c6261c65 100644
--- a/docs/FAQ.rst
+++ b/docs/FAQ.rst
@@ -53,6 +53,29 @@ Some porting problems may exist in the following areas:
like the Bourne Shell and sed. Porting to systems without these tools
(MacOS 9, Plan 9) will require more effort.
+What API do I use to store a value to one of the virtual registers in LLVM IR's SSA representation?
+---------------------------------------------------------------------------------------------------
+
+In short: you can't. It's actually kind of a silly question once you grok
+what's going on. Basically, in code like:
+
+.. code-block:: llvm
+
+ %result = add i32 %foo, %bar
+
+, ``%result`` is just a name given to the ``Value`` of the ``add``
+instruction. In other words, ``%result`` *is* the add instruction. The
+"assignment" doesn't explicitly "store" anything to any "virtual register";
+the "``=``" is more like the mathematical sense of equality.
+
+Longer explanation: In order to generate a textual representation of the
+IR, some kind of name has to be given to each instruction so that other
+instructions can textually reference it. However, the isomorphic in-memory
+representation that you manipulate from C++ has no such restriction since
+instructions can simply keep pointers to any other ``Value``'s that they
+reference. In fact, the names of dummy numbered temporaries like ``%1`` are
+not explicitly represented in the in-memory representation at all (see
+``Value::getName()``).
Build Problems
==============