[PATCH 1/2] TableGen: Generate a function for getting operand	indices based on their defined names
    Sean Silva 
    silvas at purdue.edu
       
    Mon Jun 24 14:01:31 PDT 2013
    
    
  
On Mon, Jun 24, 2013 at 12:22 PM, Tom Stellard <tom at stellard.net> wrote:
> Ping.
>
>
Oops, sorry.
+/// \p Operands [out] A map used to generate the OpName enum with operand
+///     names as its keys and operand enum values as its values.
+///  \p OperandMap [out] A map for representing the operand name mappings
for
+///     each instructions.  This is used to generate the OperandMap table
as
+///     well as the getNamedOperandIdx() function.
These are aligned differently. Also, the prevailing style in the codebase
seems to be `\param`.
+  for (unsigned i = 0, e = NumberedInstructions.size(), NumOperands = 0;
+                                                                  i != e;
++i) {
Could you pull NumOperands onto its own line before the `for` like you did
for `TableIndex` in another part of the code? I think that's a lot more
readable since it doesn't hide an unrelated variable inside the `for`
header.
+        const std::vector<const CodeGenInstruction *> NumberedInstructions,
+        std::string Namespace,
+  std::string Namespace = Target.getInstNamespace();
Do you need to be making copies here?
+    for (unsigned i = 0, e = Operands.size(); i != e; ++i)
I think this will provoke a -Wshadow warning. Best to rename the nested
loop variables like you did elsewhere (also, it would be nice if you were
consistent in the naming of the nested loop counters (`j`, `je` vs. `ii`,
`ie`)).
Other than that, it looks good to me. Jakob, any other thoughts?
-- Sean Silva
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130624/78be8a37/attachment.html>
    
    
More information about the llvm-commits
mailing list