[Bug gas/22871] New: Encode instructions of 64-bit registers without the REX_W bit
https://sourceware.org/bugzilla/show_bug.cgi?id=22871 Bug ID: 22871 Summary: Encode instructions of 64-bit registers without the REX_W bit Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: hjl.tools at gmail dot com Target Milestone: --- Target: x86-64 When the upper 32 bits of destination registers of instructions are known to be zero, we can encode them without the REX_W bit. For example, andq $imm31, %r64 xorq %r64, %r64 can be encoded as: andl $imm31, %r32 xorl %r32, %r32 To make assembler more predictable, this optimization should be done only when -O is passed to assembler. -- 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/22871] Encode instructions of 64-bit registers without the REX_W bit
https://sourceware.org/bugzilla/show_bug.cgi?id=22871 H.J. Lu changed: What|Removed |Added Version|unspecified |2.31 (HEAD) -- 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/22871] Encode instructions of 64-bit registers without the REX_W bit
https://sourceware.org/bugzilla/show_bug.cgi?id=22871
Jan Beulich changed:
What|Removed |Added
CC||jbeulich at novell dot com
--- Comment #1 from Jan Beulich ---
subq %r64, %r64 and testq $imm31, %r64 could similarly benefit. Whether
converting test{q,l,w} $imm8,%r{64,32,16} to testb $imm8,%r8 isn't as clear,
but I think reads of 8-bit registers are commonly not causing stalls (only
writes do).
Along those lines test{q,l,w} $imm,mem might allow conversion if all set bits
in imm fall within a single byte. Of course care needs to be taken that the
adjustment to the displacement won't break addressability of the object.
--
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/22871] Encode instructions of 64-bit registers without the REX_W bit
https://sourceware.org/bugzilla/show_bug.cgi?id=22871
--- Comment #2 from H.J. Lu ---
(In reply to Jan Beulich from comment #1)
> subq %r64, %r64 and testq $imm31, %r64 could similarly benefit. Whether
I added subq and testq to users/hjl/optimize branch at
https://github.com/hjl-tools/binutils-gdb/tree/users/hjl/optimize
> converting test{q,l,w} $imm8,%r{64,32,16} to testb $imm8,%r8 isn't as clear,
> but I think reads of 8-bit registers are commonly not causing stalls (only
> writes do).
>
> Along those lines test{q,l,w} $imm,mem might allow conversion if all set
> bits in imm fall within a single byte. Of course care needs to be taken that
> the adjustment to the displacement won't break addressability of the object.
Let's go with 64-bit register cases first and see how they go.
--
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 ld/15891] ia64, ld segfault on --as-needed
https://sourceware.org/bugzilla/show_bug.cgi?id=15891 --- Comment #5 from Jason Duerstock --- This appears to work as of binutils 2.30, but I was wondering if the patch included in https://sourceware.org/bugzilla/show_bug.cgi?id=15904 could have possibly fixed it as well. I will try adding it to 2.29 and see what happens WRT --as-needed. -- 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/22871] Encode instructions of 64-bit registers without the REX_W bit
https://sourceware.org/bugzilla/show_bug.cgi?id=22871 --- Comment #3 from H.J. Lu --- I updated users/hjl/optimize branch for andqimm31, mem testq imm31, mem We need to keep andqimm31, mem and optimize testq to testl imm31, mem -- 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/22871] Encode instructions of 64-bit operand without the REX_W bit
https://sourceware.org/bugzilla/show_bug.cgi?id=22871 H.J. Lu changed: What|Removed |Added Summary|Encode instructions of |Encode instructions of |64-bit registers without|64-bit operand without the |the REX_W bit |REX_W bit -- 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 gold/22838] Incorrect linking for try-catch statement for target MIPS32 R2 little endian.
https://sourceware.org/bugzilla/show_bug.cgi?id=22838 Petar Jovanovic changed: What|Removed |Added CC||mips32r2 at gmail dot com -- 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/22871] Encode instructions of 64-bit operand without the REX_W bit
https://sourceware.org/bugzilla/show_bug.cgi?id=22871 Linus Torvalds changed: What|Removed |Added CC||torvalds@linux-foundation.o ||rg --- Comment #4 from Linus Torvalds --- (In reply to H.J. Lu from comment #3) > > We need to keep > > andqimm31, mem Yes. > and optimize testq to > > testl imm31, mem This one isn't quite as obvious. There *may* be microarchitectures that could have problems doing store buffer forwarding of a previous 64-bit write to a the 32-bit read of the "testl". I _think_ all intel microarchitectures handle it fine for the "same address" case, but I'm not 100% sure. I know I've seen a table of "these forwardings are fast", but I don't recall where. The intel optimization manual does specify the rules for various microarchitectures, and they all _seem_ to state that a smaller load forwards fine from a larger store at the same address. But I don't find any generic statement that that is always true. -- 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/22871] Encode instructions of 64-bit operand without the REX_W bit
https://sourceware.org/bugzilla/show_bug.cgi?id=22871 --- Comment #5 from H.J. Lu --- (In reply to Linus Torvalds from comment #4) > (In reply to H.J. Lu from comment #3) > > > > We need to keep > > > > andqimm31, mem > > Yes. > > > and optimize testq to > > > > testl imm31, mem > > This one isn't quite as obvious. There *may* be microarchitectures that > could have problems doing store buffer forwarding of a previous 64-bit write > to a the 32-bit read of the "testl". > I updated users/hjl/optimize branch to encode testq $imm31, mem as testl $imm31, mem only at -O2. -- 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/22014] as(1) in microMIPS mode: illegal use of memcpy with overlapping addresses
https://sourceware.org/bugzilla/show_bug.cgi?id=22014 A. Wilcox changed: What|Removed |Added Version|2.29|2.30 --- Comment #2 from A. Wilcox --- This is still a bug in 2.30. -- 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 binutils/22858] Crashes found by fuzzer
https://sourceware.org/bugzilla/show_bug.cgi?id=22858
--- Comment #3 from Peng Chen ---
I really found them crash in 2.29 in my PC.
Have you limit the memory? use "ulimit -Sv 50".
They won't trigger crash with unlimited memory.
But, you know, they must be available in limited memory.
test options:
nm -C {input}
objdump -x {input}
size {input}
I just ran my fuzzer 5 hours with one core.. I will run it more in future.
--
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 binutils/22858] Crashes found by fuzzer
https://sourceware.org/bugzilla/show_bug.cgi?id=22858 Alan Modra changed: What|Removed |Added Resolution|INVALID |FIXED --- Comment #4 from Alan Modra --- Yes, I used "ulimit -Sv 50". Note that when I said I tested binutils-2.29 and binutils-2.30 I meant the current 2.29 and 2.30 branch sources, which don't crash. Indeed the binutils-2.29 release sources do crash, but we've already fixed those problems.. (I hadn't checked that until just now, which was remiss of me, and thus the proper resolution of this bug is "fixed", not "invalid".) -- 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
