From: Jeff Law <law@redhat.com>
To: Kyrill Tkachov <kyrylo.tkachov@foss.arm.com>,
Michael Matz <matz@suse.de>
Cc: Segher Boessenkool <segher@kernel.crashing.org>,
"gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] final: Improve output for -dp and -fverbose-asm
Date: Fri, 01 Dec 2017 00:25:00 -0000 [thread overview]
Message-ID: <1618e8ac-557b-fe8a-f1e7-9849bb3edd5a@redhat.com> (raw)
In-Reply-To: <5A2036D6.8000000@foss.arm.com>
On 11/30/2017 09:50 AM, Kyrill Tkachov wrote:
>
> On 30/11/17 16:47, Michael Matz wrote:
>> Hi,
>>
>> On Thu, 30 Nov 2017, Kyrill Tkachov wrote:
>>
>>>> This improves the assembler output (for -dp and -fverbose-asm)
>>>> in several ways. It always prints the insn_cost. It does not
>>>> print "[length = NN]" but "[c=NN l=NN]", to save space. It
>>>> does not add one to the instruction alternative number
>>>> (everything else starts counting those at 0, too). And
>>>> finally, it tries to keep things lined up in columns a bit
>>>> better.
>>>>
>>>> Tested on powerpc64-linux {-m32,-m64}; is this okay for trunk?
>>> FWIW printing the cost would be hepful to me at the -dp level. I
>>> agree with Martin that 'c' and 'l' are too short but using 'len'
>>> for length would be acceptable.
>> Seriously? You'd have a problem to decipher c/l but not rldicl ?
>
> I don't know what rldicl means without looking it up on the Internet
> ;) Given how frequently I have to look at these dumps, I could get
> used to any encoding though. I don't find them too verbose for my
> purposes, but if saving space is a goal here then I won't object to
> keeping them as single characters
ISTM that saving space is a goal if it generally makes the output more
readable. As we include more data in the output we do need to consider
the clutter factor. c= and l= seem reasonable to me.
There's a level of familiarity with GCC that is necessary to fully
interpret that output. However, users can still get an awful lot from
that output without immediately knowing what each and every field looks
like.
jeff
next prev parent reply other threads:[~2017-12-01 0:25 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-29 23:37 Segher Boessenkool
2017-11-30 7:52 ` Martin Sebor
2017-11-30 11:54 ` Segher Boessenkool
2017-11-30 16:06 ` Michael Matz
2017-11-30 16:36 ` Martin Sebor
2017-11-30 16:50 ` Segher Boessenkool
2017-11-30 17:02 ` Martin Sebor
2017-11-30 17:14 ` Michael Matz
2017-11-30 17:55 ` Martin Sebor
2017-12-01 0:32 ` Jeff Law
2017-12-01 22:52 ` Segher Boessenkool
2017-12-04 12:39 ` Michael Matz
2017-11-30 17:55 ` David Malcolm
2017-12-04 15:49 ` Michael Matz
2017-11-30 17:15 ` Segher Boessenkool
2017-11-30 22:59 ` Martin Sebor
2017-12-01 0:26 ` Jeff Law
2017-12-01 0:49 ` Jeff Law
2017-12-01 23:45 ` Segher Boessenkool
2017-11-30 16:44 ` Kyrill Tkachov
2017-11-30 16:54 ` Michael Matz
2017-11-30 16:55 ` Kyrill Tkachov
2017-11-30 17:07 ` Michael Matz
2017-12-01 0:22 ` Jeff Law
2017-12-01 0:25 ` Jeff Law [this message]
2017-12-01 1:17 ` Jeff Law
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1618e8ac-557b-fe8a-f1e7-9849bb3edd5a@redhat.com \
--to=law@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=kyrylo.tkachov@foss.arm.com \
--cc=matz@suse.de \
--cc=segher@kernel.crashing.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).