Hi,
On Thu, 30 Nov 2017, David Malcolm wrote:
> -fverbose-asm is on the border of compiler-debugging vs end-user usage.
I have yet to see a relevant percentage of end-users who even know what
assembler is. On the gcc.*@ and kernel.* mailing lists, sure. But Joe
Randomapp?
> FWIW an improvem
Hi,
On Thu, 30 Nov 2017, Martin Sebor wrote:
> adddi3_imm_carry_m1 seems (mostly) self-explanatory since it's built up
> of common assembly mnemonics. I confess I don't know what the number
> after # means, either on powerpc64 or on any other target.
insn uid.
> > Or, for that matter, what "
On Thu, Nov 30, 2017 at 05:49:27PM -0700, Jeff Law wrote:
> I think length and costing information are definitely things we want to
> include. Length is less of an issue now than it was in the past, but it
> definitely has value.
At least for risc targets length is usually pretty boring, but this
Hi!
On Thu, Nov 30, 2017 at 10:55:04AM -0700, Martin Sebor wrote:
> >Or, for that matter, what "length" means? Could be byte-length, sure.
> >But OTOH, for a RISC target it's always four, so why print it? The GCC
> >developers surely meant cycle-length with that, nothing else makes sense.
>
> H
On 11/29/2017 04:13 PM, Segher Boessenkool 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
On 11/30/2017 09:28 AM, Martin Sebor wrote:
> On 11/30/2017 04:16 AM, Segher Boessenkool wrote:
>> On Wed, Nov 29, 2017 at 08:46:41PM -0700, Martin Sebor wrote:
>>> On 11/29/2017 04:13 PM, Segher Boessenkool wrote:
This improves the assembler output (for -dp and -fverbose-asm) in
several
On 11/30/2017 10:55 AM, Martin Sebor wrote:
> On 11/30/2017 10:02 AM, Michael Matz wrote:
>> Hi,
>>
>> On Thu, 30 Nov 2017, Martin Sebor wrote:
>>
addic 4,9,-1 # 70 [c=4 l=4] *adddi3_imm_carry_m1
subfe 4,4,9 # 71 [c=4 l=4] *subfdi3_carry_in_internal
On 11/30/2017 03:54 PM, Martin Sebor wrote:
> On 11/30/2017 10:07 AM, Segher Boessenkool wrote:
>> On Thu, Nov 30, 2017 at 09:54:26AM -0700, Martin Sebor wrote:
It is neither line length nor amt of info that makes the second one
way better readable.
>>>
>>> The justification certainly mak
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
On 11/30/2017 09:55 AM, Michael Matz wrote:
> Hi,
>
> On Thu, 30 Nov 2017, Kyrill Tkachov wrote:
>
>> I don't know what rldicl means without looking it up on the Internet ;)
>
> :) (zero_extendsidi2/1 it seems, from Seghers dump, not that I would have
> known without)
Exactly :-) THe names
On 11/30/2017 10:07 AM, Segher Boessenkool wrote:
On Thu, Nov 30, 2017 at 09:54:26AM -0700, Martin Sebor wrote:
It is neither line length nor amt of info that makes the second one
way better readable.
The justification certainly makes it easier to read. But
the abbreviations make it harder to
On 11/30/2017 10:02 AM, Michael Matz wrote:
Hi,
On Thu, 30 Nov 2017, Martin Sebor wrote:
addic 4,9,-1 # 70 [c=4 l=4] *adddi3_imm_carry_m1
subfe 4,4,9 # 71 [c=4 l=4] *subfdi3_carry_in_internal
b .L5# 81 [c=4 l=4] jump
Not everyone who read
On Thu, 2017-11-30 at 18:02 +0100, Michael Matz wrote:
> Hi,
>
> On Thu, 30 Nov 2017, Martin Sebor wrote:
>
> > > addic 4,9,-1 # 70 [c=4 l=4] *adddi3_imm_carry_m1
> > > subfe 4,4,9 # 71 [c=4
> > > l=4] *subfdi3_carry_in_internal
> > > b .L5# 81
On Thu, Nov 30, 2017 at 09:54:26AM -0700, Martin Sebor wrote:
> >It is neither line length nor amt of info that makes the second one
> >way better readable.
>
> The justification certainly makes it easier to read. But
> the abbreviations make it harder to interpret. [c=4 l=4]
> makes no sense to
Hi,
On Thu, 30 Nov 2017, Martin Sebor wrote:
> > addic 4,9,-1 # 70 [c=4 l=4] *adddi3_imm_carry_m1
> > subfe 4,4,9 # 71 [c=4 l=4] *subfdi3_carry_in_internal
> > b .L5# 81 [c=4 l=4] jump
>
> Not everyone who reads the verbose assembly is famili
Hi,
On Thu, 30 Nov 2017, Kyrill Tkachov wrote:
> I don't know what rldicl means without looking it up on the Internet ;)
:) (zero_extendsidi2/1 it seems, from Seghers dump, not that I would have
known without)
> Given how frequently I have to look at these dumps, I could get used to
> any
On 11/30/2017 09:44 AM, Segher Boessenkool wrote:
On Thu, Nov 30, 2017 at 09:28:44AM -0700, Martin Sebor wrote:
The point is that [length = 12] takes up an awful lot of space. The
output of -fverbose-asm alread suffers from information overload.
Amount of space vs amount of detail are two dif
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
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 alternat
On Thu, Nov 30, 2017 at 09:28:44AM -0700, Martin Sebor wrote:
> >The point is that [length = 12] takes up an awful lot of space. The
> >output of -fverbose-asm alread suffers from information overload.
>
> Amount of space vs amount of detail are two different concerns.
Yes.
> If you feel that t
Hi Segher,
On 29/11/17 23:13, Segher Boessenkool 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
On 11/30/2017 04:16 AM, Segher Boessenkool wrote:
On Wed, Nov 29, 2017 at 08:46:41PM -0700, Martin Sebor wrote:
On 11/29/2017 04:13 PM, Segher Boessenkool wrote:
This improves the assembler output (for -dp and -fverbose-asm) in
several ways. It always prints the insn_cost. It does not print
"
Hi,
On Thu, 30 Nov 2017, Segher Boessenkool wrote:
> > [c=NN l=NN] will be meaningless to those without some deeper insight
> > into/experience with what's actually being printed. It might as well
> > say [NN NN]. But such extreme terseness would
>
> Length isn't printed on all targets, fwiw.
On Wed, Nov 29, 2017 at 08:46:41PM -0700, Martin Sebor wrote:
> On 11/29/2017 04:13 PM, Segher Boessenkool 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 s
On 11/29/2017 04:13 PM, Segher Boessenkool 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 (every
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 fi
26 matches
Mail list logo
