llvm dev - Dec 2012 - [LLVMdev] Getting rid of tabs in LLVM's assembly output?

On Dec 18, 2012, at 2:07 PM, Chandler Carruth <chandlerc at google.com>
wrote:
> On Tue, Dec 18, 2012 at 1:13 PM, Eli Bendersky <eliben at google.com>
wrote:
> On Tue, Dec 18, 2012 at 1:09 PM, Craig Topper <craig.topper at
gmail.com> wrote:
> > But its pretty easy to change the tabstop within the editor to make it
> > readable.
> >
> 
> True, in this case... The output is not trying to be intelligent in
> the general case, just spitting out tabs. I agree that to replace
> this, however, it would be best to look at some smart column-padded
> formatting than use a constant tab -> N spaces replacement. I'll see
> if this is something I can get to.
> 
> Maybe it's naive, but I would expect it to be easy for each backend to
expose a constant N which is the length of the longest mnemonic, and then for
the printer to pad to N+1 or N+2….
That would probably work for X86, but other targets (ARM in particular) often
have operands which are printed/parsed as suffices on the mnemonic itself. 
Because of these, the backend does not statically know the longest potential
string-of-stuff-before-the-tab.

--Owen

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20121218/d20179a0/attachment.html>

> > Maybe it's naive, but I would expect it to be easy for each
backend to
> > expose a constant N which is the length of the longest mnemonic, and
then
> > for the printer to pad to N+1 or N+2….
>
> That would probably work for X86, but other targets (ARM in particular)
> often have operands which are printed/parsed as suffices on the mnemonic
> itself.  Because of these, the backend does not statically know the longest
> potential string-of-stuff-before-the-tab.
Are you thinking of something beyond the ".F32.I16" suffixes (for
example)? If not, the result may not be TableGeneratable, but is
probably conservatively known as "8 + natural mnemonic length" for
these purposes.

Tim.

(N.b. I have been looking almost exclusively at the 64-bit
architecture for the last year, I could well be massively wrong about
the 32-bit world).

On Tue, Dec 18, 2012 at 3:36 PM, Tim Northover <t.p.northover at
gmail.com>wrote:
> > > Maybe it's naive, but I would expect it to be easy for each
backend to
> > > expose a constant N which is the length of the longest mnemonic,
and
> then
> > > for the printer to pad to N+1 or N+2….
> >
> > That would probably work for X86, but other targets (ARM in
particular)
> > often have operands which are printed/parsed as suffices on the
mnemonic
> > itself.  Because of these, the backend does not statically know the
> longest
> > potential string-of-stuff-before-the-tab.
>
> Are you thinking of something beyond the ".F32.I16" suffixes (for
> example)? If not, the result may not be TableGeneratable, but is
> probably conservatively known as "8 + natural mnemonic length"
for
> these purposes.
>
The great thing is, if its close enough, it doesn't matter if there exist
corner cases that are formatted less well.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20121218/cee8616c/attachment.html>

On Tue, Dec 18, 2012 at 3:21 PM, Owen Anderson <resistor at mac.com>
wrote:
>
> On Dec 18, 2012, at 2:07 PM, Chandler Carruth <chandlerc at
google.com> wrote:
>
> On Tue, Dec 18, 2012 at 1:13 PM, Eli Bendersky <eliben at google.com>
wrote:
>>
>> On Tue, Dec 18, 2012 at 1:09 PM, Craig Topper <craig.topper at
gmail.com>
>> wrote:
>> > But its pretty easy to change the tabstop within the editor to
make it
>> > readable.
>> >
>>
>> True, in this case... The output is not trying to be intelligent in
>> the general case, just spitting out tabs. I agree that to replace
>> this, however, it would be best to look at some smart column-padded
>> formatting than use a constant tab -> N spaces replacement. I'll
see
>> if this is something I can get to.
>
>
> Maybe it's naive, but I would expect it to be easy for each backend to
> expose a constant N which is the length of the longest mnemonic, and then
> for the printer to pad to N+1 or N+2….
>
>
> That would probably work for X86, but other targets (ARM in particular)
> often have operands which are printed/parsed as suffices on the mnemonic
> itself.  Because of these, the backend does not statically know the longest
> potential string-of-stuff-before-the-tab.
>
Even if in some freak cases the formatting isn't perfect, it can still
be a massive improvement if the pad-to-column formatter is used in
tandem with Chandler's suggestion. Don't forget that the current
situation is to just emit a single tab after each instruction, so even
relatively simple cases get formatted badly.

Eli