[llvm-commits] [llvm] r77499 - /llvm/trunk/utils/TableGen/AsmWriterEmitter.cpp

Daniel Dunbar daniel at zuster.org
Thu Jul 30 20:22:12 PDT 2009


I don't really understand this discussion.

There should be enough information in the .td file to split the
assembly string into "operands" (in the assembler use of the term, not
the LLVM use). If there isn't, we will eventually need it for the
assembler parser -- currently it is inferring that information by a
sloppy tokenization of the output assembler string.

Given that this information exists (and must exist, for the assembler
parser to work), it follows that the .td file doesn't need any changes
to support lining the operands up into columns.

Since the assembler parser will need strictly more information than
formatted output, it seems to me to make more sense to focus on where
we don't currently have enough information for it.

Does this make sense?

 - Daniel

On Thu, Jul 30, 2009 at 7:34 PM, Chris Lattner<clattner at apple.com> wrote:
>
> On Jul 30, 2009, at 3:15 PM, David A. Greene wrote:
>
>> On Thursday 30 July 2009 16:12, Chris Lattner wrote:
>>
>>>>  And
>>>> not everyone wants this kind of padding.  A tab is a bit much for
>>>> some folks
>>>> and that's completely understandable.
>>>
>>> I'm not sure why someone wouldn't want this.  IF they don't want
>>> indentation, they can just not use \t??
>>
>> This isn't indentation.  This is a patch to line up operands, like
>> this:
>>
>> opcode                op1,       op2,       [op3+op4]
>> opcode                [op1+op2], op3,       op4
>>
>> Some people like the way things are now:
>>
>> opcode                op1, op2, [op3+op4]
>> opcode                [op1+op2], op3, op4
>>
>> and won't like (with tabs):
>>
>> opcode                op1,    op2,    [op3+op4]
>> opcode                [op1+op2],      op3,    op4
>>
>> So once we start putting tabs in .td files everyone is stuck with
>> them.
>
> Too bad.  We can do the right thing for each target.  We don't have to
> support "indent" style rules for .s files, just pick one approach and
> be consistent.  Since you care them most about this, you can pick the
> rules.
>
> -Chris
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>




More information about the llvm-commits mailing list