[Bug target/52352] [x32] - Wrong code to access addresses 0x80000000 to 0xFFFFFFFF using registers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52352 --- Comment #14 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2012-02-27 16:48:36 UTC --- Author: hjl Date: Mon Feb 27 16:48:26 2012 New Revision: 184604 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=184604 Log: Enable *movabsmode_[12] only for TARGET_LP64 2012-02-27 H.J. Lu hongjiu...@intel.com PR target/52352 * config/i386/i386.md (*movabsmode_1): Enable only for TARGET_LP64. (*movabsmode_2): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.md
[Bug target/52352] [x32] - Wrong code to access addresses 0x80000000 to 0xFFFFFFFF using registers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52352 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Target Milestone|--- |4.7.0 --- Comment #15 from Uros Bizjak ubizjak at gmail dot com 2012-02-27 23:05:12 UTC --- Fixed for 4.7.
[Bug target/52352] [x32] - Wrong code to access addresses 0x80000000 to 0xFFFFFFFF using registers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52352
--- Comment #10 from Uros Bizjak ubizjak at gmail dot com 2012-02-24 18:32:56
UTC ---
(In reply to comment #9)
It is fixed on hjl/x32/addr32, hjl/x32/gcc-4_6-branch and
hjl/x32/gcc-4_6-branch+mx32 branches.
The problem is
;; Stores and loads of ax to arbitrary constant address.
;; We fake an second form of instruction to force reload to load address
;; into register when rax is not available
(define_insn *movabsmode_1
[(set (mem:SWI1248x (match_operand:DI 0 x86_64_movabs_operand i,r))
(match_operand:SWI1248x 1 nonmemory_operand a,er))]
TARGET_64BIT ix86_check_movabs (insn, 0)
@
movabs{imodesuffix}\t{%1, %P0|%P0, %1}
mov{imodesuffix}\t{%1, %a0|%a0, %1}
DImode is incorrect for x32, especially for register operand.
That is where
movq$-18874360, %rax
movl(%rax), %edx
comes from. It should be in Pmode. However, the immediate operand
must be in DImode for x86_64_movabs_operand.
But this is the _address_ that we are talking, see the MEM RTX. So, following
(untested) patch can help - access is in PTR mode, and a modifier should
handle this without problems.
--cut here--
Index: config/i386/i386.md
===
--- config/i386/i386.md (revision 184560)
+++ config/i386/i386.md (working copy)
@@ -2360,7 +2360,7 @@
;; We fake an second form of instruction to force reload to load address
;; into register when rax is not available
(define_insn *movabsmode_1
- [(set (mem:SWI1248x (match_operand:DI 0 x86_64_movabs_operand i,r))
+ [(set (mem:SWI1248x (match_operand:PTR 0 x86_64_movabs_operand i,r))
(match_operand:SWI1248x 1 nonmemory_operand a,er))]
TARGET_64BIT ix86_check_movabs (insn, 0)
@
@@ -2375,7 +2375,7 @@
(define_insn *movabsmode_2
[(set (match_operand:SWI1248x 0 register_operand =a,r)
-(mem:SWI1248x (match_operand:DI 1 x86_64_movabs_operand i,r)))]
+(mem:SWI1248x (match_operand:PTR 1 x86_64_movabs_operand i,r)))]
TARGET_64BIT ix86_check_movabs (insn, 1)
@
movabs{imodesuffix}\t{%P1, %0|%0, %P1}
--cut here--
[Bug target/52352] [x32] - Wrong code to access addresses 0x80000000 to 0xFFFFFFFF using registers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52352
--- Comment #11 from H.J. Lu hjl.tools at gmail dot com 2012-02-24 19:14:19
UTC ---
(In reply to comment #10)
But this is the _address_ that we are talking, see the MEM RTX. So,
following
(untested) patch can help - access is in PTR mode, and a modifier should
handle this without problems.
--cut here--
Index: config/i386/i386.md
===
--- config/i386/i386.md (revision 184560)
+++ config/i386/i386.md (working copy)
@@ -2360,7 +2360,7 @@
;; We fake an second form of instruction to force reload to load address
;; into register when rax is not available
(define_insn *movabsmode_1
- [(set (mem:SWI1248x (match_operand:DI 0 x86_64_movabs_operand i,r))
+ [(set (mem:SWI1248x (match_operand:PTR 0 x86_64_movabs_operand i,r))
(match_operand:SWI1248x 1 nonmemory_operand a,er))]
TARGET_64BIT ix86_check_movabs (insn, 0)
@
@@ -2375,7 +2375,7 @@
(define_insn *movabsmode_2
[(set (match_operand:SWI1248x 0 register_operand =a,r)
-(mem:SWI1248x (match_operand:DI 1 x86_64_movabs_operand i,r)))]
+(mem:SWI1248x (match_operand:PTR 1 x86_64_movabs_operand i,r)))]
TARGET_64BIT ix86_check_movabs (insn, 1)
@
movabs{imodesuffix}\t{%P1, %0|%0, %P1}
--cut here--
I checked a similar fix into hjl/x32/addr32, hjl/x32/gcc-4_6-branch and
hjl/x32/gcc-4_6-branch+mx32 branches. I also added I code to print
constant address as positive 32bit integer for x32:
http://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=c6d9aee05cb3bfbe3c2a1b63f3f842e8d3fcb8e0
I used :P instead of :PTR which will be removed when I submit patches
to use SImode for Pmode with x32.
[Bug target/52352] [x32] - Wrong code to access addresses 0x80000000 to 0xFFFFFFFF using registers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52352 --- Comment #12 from Uros Bizjak ubizjak at gmail dot com 2012-02-24 19:29:20 UTC --- (In reply to comment #11) I checked a similar fix into hjl/x32/addr32, hjl/x32/gcc-4_6-branch and hjl/x32/gcc-4_6-branch+mx32 branches. I also added I code to print constant address as positive 32bit integer for x32: I think we can simply disable these two patterns on x32. This is with disabled patterns: x32_O3_main: 0: b8 00 00 e0 fe mov$0xfee0,%eax 5: 8b 00 mov(%rax),%eax 7: a8 01 test $0x1,%al 9: 74 01 je c x32_O3_main+0xc b: 90 nop c: b8 00 00 e0 fe mov$0xfee0,%eax 11: 8b 50 08mov0x8(%rax),%edx 14: 89 50 04mov%edx,0x4(%rax) 17: c3 retq and with enabled patterns: x32_O3_main: 0: a1 00 00 e0 fe 00 00movabs 0xfee0,%eax 7: 00 00 9: a8 01 test $0x1,%al b: 74 01 je e x32_O3_main+0xe d: 90 nop e: a1 08 00 e0 fe 00 00movabs 0xfee8,%eax 15: 00 00 17: a3 04 00 e0 fe 00 00movabs %eax,0xfee4 1e: 00 00 20: c3 retq There is simply no need for movabs from/to mem, since there is no 64bit addresses. And code size is horrible (and I bet that the former code runs faster).
[Bug target/52352] [x32] - Wrong code to access addresses 0x80000000 to 0xFFFFFFFF using registers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52352 --- Comment #13 from H.J. Lu hjl.tools at gmail dot com 2012-02-24 20:03:59 UTC --- (In reply to comment #12) (In reply to comment #11) I checked a similar fix into hjl/x32/addr32, hjl/x32/gcc-4_6-branch and hjl/x32/gcc-4_6-branch+mx32 branches. I also added I code to print constant address as positive 32bit integer for x32: I think we can simply disable these two patterns on x32. This is with disabled patterns: x32_O3_main: 0: b8 00 00 e0 fe mov$0xfee0,%eax 5: 8b 00 mov(%rax),%eax 7: a8 01 test $0x1,%al 9: 74 01 je c x32_O3_main+0xc b: 90 nop c: b8 00 00 e0 fe mov$0xfee0,%eax 11: 8b 50 08mov0x8(%rax),%edx 14: 89 50 04mov%edx,0x4(%rax) 17: c3 retq and with enabled patterns: x32_O3_main: 0: a1 00 00 e0 fe 00 00movabs 0xfee0,%eax 7: 00 00 9: a8 01 test $0x1,%al b: 74 01 je e x32_O3_main+0xe d: 90 nop e: a1 08 00 e0 fe 00 00movabs 0xfee8,%eax 15: 00 00 17: a3 04 00 e0 fe 00 00movabs %eax,0xfee4 1e: 00 00 20: c3 retq There is simply no need for movabs from/to mem, since there is no 64bit addresses. And code size is horrible (and I bet that the former code runs faster). I think it is a good idea.
[Bug target/52352] [x32] - Wrong code to access addresses 0x80000000 to 0xFFFFFFFF using registers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52352 --- Comment #1 from Steffen Schmidt steffen-schmidt at siemens dot com 2012-02-23 11:38:50 UTC --- Created attachment 26728 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26728 Generated -mx32 -O3 assembler
[Bug target/52352] [x32] - Wrong code to access addresses 0x80000000 to 0xFFFFFFFF using registers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52352 --- Comment #2 from Steffen Schmidt steffen-schmidt at siemens dot com 2012-02-23 11:39:26 UTC --- Created attachment 26729 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26729 Generated -mx32 -O1 assembler
[Bug target/52352] [x32] - Wrong code to access addresses 0x80000000 to 0xFFFFFFFF using registers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52352 --- Comment #3 from Steffen Schmidt steffen-schmidt at siemens dot com 2012-02-23 11:40:01 UTC --- Created attachment 26730 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26730 Generated -m64 -O3 assembler
[Bug target/52352] [x32] - Wrong code to access addresses 0x80000000 to 0xFFFFFFFF using registers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52352 --- Comment #4 from Steffen Schmidt steffen-schmidt at siemens dot com 2012-02-23 11:40:41 UTC --- Created attachment 26731 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26731 Generated -m64 -O1 assembler
[Bug target/52352] [x32] - Wrong code to access addresses 0x80000000 to 0xFFFFFFFF using registers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52352 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #5 from Uros Bizjak ubizjak at gmail dot com 2012-02-23 16:43:16 UTC --- This works OK with gcc-4.7: // -mx32 -O3 movabsl 4276092936, %eax movabsl %eax, 4276092932 ret H.J. probably needs to backport a patch or two from mainline.
[Bug target/52352] [x32] - Wrong code to access addresses 0x80000000 to 0xFFFFFFFF using registers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52352 --- Comment #6 from Uros Bizjak ubizjak at gmail dot com 2012-02-23 16:47:00 UTC --- (In reply to comment #5) H.J. probably needs to backport a patch or two from mainline. BTW: Please report problems with non-FSF branches directly to their respective authors. There is no -mx32 switch in official 4.6.x, so please try to trigger the x32 specific bug with gcc-4.7.x before reporting it in bugzilla.
[Bug target/52352] [x32] - Wrong code to access addresses 0x80000000 to 0xFFFFFFFF using registers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52352 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #7 from Andrew Pinski pinskia at gcc dot gnu.org 2012-02-23 17:27:29 UTC --- Since 4.6.x did not have -mx32 I am just going to close this as a dup of the one which was reported against 4.7. The branch you are using is not an officially supported branch and you should report bugs to HJL directly. *** This bug has been marked as a duplicate of bug 52146 ***
[Bug target/52352] [x32] - Wrong code to access addresses 0x80000000 to 0xFFFFFFFF using registers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52352 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Last reconfirmed||2012-02-24 Resolution|DUPLICATE | Ever Confirmed|0 |1 --- Comment #8 from H.J. Lu hjl.tools at gmail dot com 2012-02-24 04:46:58 UTC --- Working on a fix.
[Bug target/52352] [x32] - Wrong code to access addresses 0x80000000 to 0xFFFFFFFF using registers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52352
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution||FIXED
--- Comment #9 from H.J. Lu hjl.tools at gmail dot com 2012-02-24 04:53:04
UTC ---
It is fixed on hjl/x32/addr32, hjl/x32/gcc-4_6-branch and
hjl/x32/gcc-4_6-branch+mx32 branches.
The problem is
;; Stores and loads of ax to arbitrary constant address.
;; We fake an second form of instruction to force reload to load address
;; into register when rax is not available
(define_insn *movabsmode_1
[(set (mem:SWI1248x (match_operand:DI 0 x86_64_movabs_operand i,r))
(match_operand:SWI1248x 1 nonmemory_operand a,er))]
TARGET_64BIT ix86_check_movabs (insn, 0)
@
movabs{imodesuffix}\t{%1, %P0|%P0, %1}
mov{imodesuffix}\t{%1, %a0|%a0, %1}
DImode is incorrect for x32, especially for register operand.
That is where
movq$-18874360, %rax
movl(%rax), %edx
comes from. It should be in Pmode. However, the immediate operand
must be in DImode for x86_64_movabs_operand. Changing this condition
is very intrusive. On the other hand, the second form is redundant
and I opened PR 52364 for it. My fix simply removes the second form:
http://gcc.gnu.org/git/?p=gcc.git;a=commit;h=eb7964e69f1d7d478ae99ae6eff080f15af2b074
