This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] final: Improve output for -dp and -fverbose-asm
- From: Jeff Law <law at redhat dot com>
- To: Kyrill Tkachov <kyrylo dot tkachov at foss dot arm dot com>, Michael Matz <matz at suse dot de>
- Cc: Segher Boessenkool <segher at kernel dot crashing dot org>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 30 Nov 2017 17:25:29 -0700
- Subject: Re: [PATCH] final: Improve output for -dp and -fverbose-asm
- Authentication-results: sourceware.org; auth=none
- References: <ac47cf30cab2820e22831de664d8d42964705d88.1511996668.git.segher@kernel.crashing.org> <5A203385.1040708@foss.arm.com> <alpine.LSU.2.21.1711301746320.25295@wotan.suse.de> <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