[Bug gas/18427] GNU as slow on hppa architecture
https://sourceware.org/bugzilla/show_bug.cgi?id=18427 John David Anglin danglin at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||danglin at gcc dot gnu.org Resolution|--- |FIXED --- Comment #10 from John David Anglin danglin at gcc dot gnu.org --- Should be fixed on master: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=18c208b2292f3c61097dee99053ecab78b393e46 -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/18427] GNU as slow on hppa architecture
https://sourceware.org/bugzilla/show_bug.cgi?id=18427 --- Comment #7 from Nick Clifton nickc at redhat dot com --- Hi Dave, Your patch is approved - please apply it when you have the time. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/18427] GNU as slow on hppa architecture
https://sourceware.org/bugzilla/show_bug.cgi?id=18427 --- Comment #8 from dave.anglin at bell dot net --- On 6/8/2015 6:19 AM, nickc at redhat dot com wrote: Your patch is approved - please apply it when you have the time. Are there guidelines for git commits somewhere? I'll give this a try tonight. Regards, Dave -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/18427] GNU as slow on hppa architecture
https://sourceware.org/bugzilla/show_bug.cgi?id=18427 --- Comment #9 from Nick Clifton nickc at redhat dot com --- Hi Dave, Are there guidelines for git commits somewhere? Surprisingly: no. :-( Basically the guidelines are as follows: * Test your patch before committing it. * Include a ChangeLog entry/entries. * Include a testcase if possible/appropriate. * In the commit message, start with a single sentence that describes the change, then leave a blank line, then include the changelog entries. That's about it. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/18427] GNU as slow on hppa architecture
https://sourceware.org/bugzilla/show_bug.cgi?id=18427
--- Comment #6 from dave.anglin at bell dot net ---
Hi Nick,
On 2015-06-01 4:01 AM, nickc at redhat dot com wrote:
https://sourceware.org/bugzilla/show_bug.cgi?id=18427
--- Comment #5 from Nick Clifton nickc at redhat dot com ---
Hi Dave,
Thanks for helping with this change.
I'm not sure about the option. Alpha has somewhat similar code without
an option.
As I understand it, this code is to handle a number of instructions
which require a preceding
label. It usually emitted on the previous line. It seems to me that
changing segments between
the label and its related instruction should be an error. I don't think
this feature is needed
even for the HP-UX SOM target.
I will check whether GCC needs this for SOM.
OK - thanks. If you can confirm that support for this behaviour is no
longer needed then I will be happy to go with the simpler patch. (Or
maybe the simpler one + an error message if the preceding label cannot
be found). I just did not want to break anybody's builds because of a
speed optimization,
Attached is a change to implement the above handling for the last label.
The gas testsuite for the hpux SOM target is clean. There are four
fails with 64-bit
hpux ELF target. None of these appear related to the change. Haven't
tested linux yet.
The 64-bit gas fails are:
FAIL: gas/all/none
FAIL: Multibyte symbol names
FAIL: weak and common directives
FAIL: common and weak directives
The latter two are caused by the behavior of the .comm directive. These
two would pass
with foobar label before the .comm.
We have for gas/all/none:
# ../as-new -o dump.o none.s
# /opt/gnu64/bin/objdump -r -w dump.o
dump.o: file format elf64-hppa
RELOCATION RECORDS FOR [.text]:
OFFSET TYPE VALUE
R_PARISC_PCREL64 *ABS*
We have for Multibyte symbol names:
# ../as-new -o dump.o syms.s
# /opt/gnu64/bin/readelf -S -s -p .strtab dump.o
There are 8 section headers, starting at offset 0x120:
Section Headers:
[Nr] Name Type Address Offset
Size EntSize Flags Link Info Align
[ 0] NULL
0 0 0
[ 1] .text PROGBITS 0040
AX 0 0 1
[ 2] .data PROGBITS 0040
WA 0 0 1
[ 3] .bss NOBITS 0040
WA 0 0 1
[ 4] sec▒▒tion PROGBITS 0040
0009 0 0 1
[ 5] .shstrtab STRTAB 00ea
0036 0 0 1
[ 6] .symtab SYMTAB 0050
0090 0018 7 6 8
[ 7] .strtab STRTAB 00e0
000a 0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings)
I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
O (extra OS processing required) o (OS specific), p (processor specific)
Symbol table '.symtab' contains 6 entries:
Num:Value Size TypeBind Vis Ndx Name
0: 0 NOTYPE LOCAL DEFAULT UND
1: 0 SECTION LOCAL DEFAULT1
2: 0 SECTION LOCAL DEFAULT2
3: 0 SECTION LOCAL DEFAULT3
4: 0 SECTION LOCAL DEFAULT4
5: 0 NOTYPE LOCAL DEFAULT4 sy▒▒mbol
String dump of section '.strtab':
[tx] sy▒▒mbol
Dave
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/18427] GNU as slow on hppa architecture
https://sourceware.org/bugzilla/show_bug.cgi?id=18427 --- Comment #5 from Nick Clifton nickc at redhat dot com --- Hi Dave, Thanks for helping with this change. I'm not sure about the option. Alpha has somewhat similar code without an option. As I understand it, this code is to handle a number of instructions which require a preceding label. It usually emitted on the previous line. It seems to me that changing segments between the label and its related instruction should be an error. I don't think this feature is needed even for the HP-UX SOM target. I will check whether GCC needs this for SOM. OK - thanks. If you can confirm that support for this behaviour is no longer needed then I will be happy to go with the simpler patch. (Or maybe the simpler one + an error message if the preceding label cannot be found). I just did not want to break anybody's builds because of a speed optimization, Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/18427] GNU as slow on hppa architecture
https://sourceware.org/bugzilla/show_bug.cgi?id=18427 Nick Clifton nickc at redhat dot com changed: What|Removed |Added Status|NEW |ASSIGNED -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/18427] GNU as slow on hppa architecture
https://sourceware.org/bugzilla/show_bug.cgi?id=18427 Nick Clifton nickc at redhat dot com changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #3 from Nick Clifton nickc at redhat dot com --- Created attachment 8336 -- https://sourceware.org/bugzilla/attachment.cgi?id=8336action=edit Extended patch Hi Guys, I dislike the idea of disabling code that might actually be needed in some circumstances. So how about this alternative patch ? It extends David's patch by adding a command line option: --enable-multi-seg-support. If this option is used the old, slow, searching code is used. Otherwise the default action is to use the new, faster search code. What do you think, will this work ? Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/18427] GNU as slow on hppa architecture
https://sourceware.org/bugzilla/show_bug.cgi?id=18427 --- Comment #4 from dave.anglin at bell dot net --- On 2015-05-29 12:20 PM, nickc at redhat dot com wrote: I dislike the idea of disabling code that might actually be needed in some circumstances. So how about this alternative patch ? It extends David's patch by adding a command line option: --enable-multi-seg-support. If this option is used the old, slow, searching code is used. Otherwise the default action is to use the new, faster search code. Hi Nick, Thanks for helping with this change. I'm not sure about the option. Alpha has somewhat similar code without an option. As I understand it, this code is to handle a number of instructions which require a preceding label. It usually emitted on the previous line. It seems to me that changing segments between the label and its related instruction should be an error. I don't think this feature is needed even for the HP-UX SOM target. I will check whether GCC needs this for SOM. Dave -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/18427] GNU as slow on hppa architecture
https://sourceware.org/bugzilla/show_bug.cgi?id=18427 --- Comment #1 from Helge Deller deller at gmx dot de --- Created attachment 8324 -- https://sourceware.org/bugzilla/attachment.cgi?id=8324action=edit initial version of a proposed patch -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/18427] GNU as slow on hppa architecture
https://sourceware.org/bugzilla/show_bug.cgi?id=18427 --- Comment #2 from dave.anglin at bell dot net --- On 2015-05-18, at 3:15 PM, deller at gmx dot de wrote: So, the pa_undefine_label() function seems problematic. I talked to Dave Anglin about that issue, and he came up with the attached patch. This patch seems to work and speeds up gas a lot, but it will most likely break HP-UX (which uses multiple segments). Actually, ELF targets such as Linux have multiple segments. Assembly time blows up when -ffunction-sections and -fdata-sections are used. The lists for each segment are poorly managed, so both the number of lists and their length grows. All this overhead is to find the previous label emitted in the current space/segment. In practice, GCC never plays with spaces/segments between emitting the label and its associated instruction. So, the previous label is what's needed. The tracking is for hand crafted assembly code. The patch doesn't affect 32-bit HP-UX SOM. The patch might affect 64-bit HP-UX. I haven't tried it on 64-bit HP-UX. -- John David Anglin dave.ang...@bell.net -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
