[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