| Message ID | CAMe9rOr_DWO9ac04F2zv_Un0_xSUqmvp55fLeHaDPi4P=DRuDA@mail.gmail.com |
|---|---|
| State | New |
| Headers | show |
On 07/21/2011 09:13 AM, H.J. Lu wrote: >> > PR target/49798 >> > * config/i386/i386.c (ix86_asm_integer): New. >> > (TARGET_ASM_INTEGER): Likewise. >> > > This is the updated patch, using the same approach in sparc_assemble_integer. > OK for trunk? Is there any reason why we don't simply accept .quad in the assembler? It seems like this is making us jump through hoops for no reason. r~
On Thu, Jul 21, 2011 at 9:15 AM, Richard Henderson <rth@redhat.com> wrote: > On 07/21/2011 09:13 AM, H.J. Lu wrote: >>> > PR target/49798 >>> > * config/i386/i386.c (ix86_asm_integer): New. >>> > (TARGET_ASM_INTEGER): Likewise. >>> > >> This is the updated patch, using the same approach in sparc_assemble_integer. >> OK for trunk? > > Is there any reason why we don't simply accept .quad in the assembler? > It seems like this is making us jump through hoops for no reason. > ".quad symbol" isn't really valid for 32bit. I can add a new ".xquad" directive, similar to ".xword" for sparc, to treat it as .long symbol .long 0 If this is preferred, I can prepare a new patch to generate ".xquad".
On 07/21/2011 09:20 AM, H.J. Lu wrote: > ".quad symbol" isn't really valid for 32bit. Why not? We certainly know what value to put there. > I can add a new ".xquad" directive, > similar to ".xword" for sparc... That seems like exactly the same meaningless complication. r~
On Thu, Jul 21, 2011 at 9:23 AM, Richard Henderson <rth@redhat.com> wrote: > On 07/21/2011 09:20 AM, H.J. Lu wrote: >> ".quad symbol" isn't really valid for 32bit. > > Why not? We certainly know what value to put there. > x32 doesn't support 64bit relocation, like R_X86_64_64. In many causes, generate .long symbol .long 0 for ".quad symbol" is wrong. Please see: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47446 for some examples.
On 07/21/2011 09:28 AM, H.J. Lu wrote: > On Thu, Jul 21, 2011 at 9:23 AM, Richard Henderson <rth@redhat.com> wrote: >> On 07/21/2011 09:20 AM, H.J. Lu wrote: >>> ".quad symbol" isn't really valid for 32bit. >> >> Why not? We certainly know what value to put there. >> > > x32 doesn't support 64bit relocation, like R_X86_64_64. This being a self-fulfilling assertion, because you decided to disable that relocation. It *could* be supported. Easily. r~
On Thu, Jul 21, 2011 at 6:28 PM, H.J. Lu <hjl.tools@gmail.com> wrote: >>> ".quad symbol" isn't really valid for 32bit. >> >> Why not? We certainly know what value to put there. >> > > x32 doesn't support 64bit relocation, like R_X86_64_64. > In many causes, generate > > .long symbol > .long 0 > > for ".quad symbol" is wrong. Please see: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47446 > > for some examples. Please also see: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49798#c12 on why I think this is middle-end/tree-optimization issue. Uros.
On Thu, Jul 21, 2011 at 10:04 AM, Uros Bizjak <ubizjak@gmail.com> wrote: > On Thu, Jul 21, 2011 at 6:28 PM, H.J. Lu <hjl.tools@gmail.com> wrote: > >>>> ".quad symbol" isn't really valid for 32bit. >>> >>> Why not? We certainly know what value to put there. >>> >> >> x32 doesn't support 64bit relocation, like R_X86_64_64. >> In many causes, generate >> >> .long symbol >> .long 0 >> >> for ".quad symbol" is wrong. Please see: >> >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47446 >> >> for some examples. > > Please also see: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49798#c12 > > on why I think this is middle-end/tree-optimization issue. > I still think it is a backend issue.
On Thu, Jul 21, 2011 at 7:24 PM, H.J. Lu <hjl.tools@gmail.com> wrote: > On Thu, Jul 21, 2011 at 10:04 AM, Uros Bizjak <ubizjak@gmail.com> wrote: >> On Thu, Jul 21, 2011 at 6:28 PM, H.J. Lu <hjl.tools@gmail.com> wrote: >> >>>>> ".quad symbol" isn't really valid for 32bit. >>>> >>>> Why not? We certainly know what value to put there. >>>> >>> >>> x32 doesn't support 64bit relocation, like R_X86_64_64. >>> In many causes, generate >>> >>> .long symbol >>> .long 0 >>> >>> for ".quad symbol" is wrong. Please see: >>> >>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47446 >>> >>> for some examples. >> >> Please also see: >> >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49798#c12 >> >> on why I think this is middle-end/tree-optimization issue. >> > > I still think it is a backend issue. /* Represents viewing something of one type as being of a second type. This corresponds to an "Unchecked Conversion" in Ada and roughly to the idiom *(type2 *)&X in C. The only operand is the value to be viewed as being of another type. **It is undefined if the type of the input and of the expression have different sizes.** ... DEFTREECODE (VIEW_CONVERT_EXPR, "view_convert_expr", tcc_reference, 1) We have: <bb 2>: D.2709_8 = VIEW_CONVERT_EXPR<double>(&xxxx); D.2702_1 = u.d; D.2704_3 = D.2702_1 == D.2709_8; D.2701_4 = (int) D.2704_3; return D.2701_4; Where sizeof (double) = 64 sizeof (ptr_type) = 32. Uros.
On Thu, Jul 21, 2011 at 9:42 AM, Richard Henderson <rth@redhat.com> wrote: > On 07/21/2011 09:28 AM, H.J. Lu wrote: >> On Thu, Jul 21, 2011 at 9:23 AM, Richard Henderson <rth@redhat.com> wrote: >>> On 07/21/2011 09:20 AM, H.J. Lu wrote: >>>> ".quad symbol" isn't really valid for 32bit. >>> >>> Why not? We certainly know what value to put there. >>> >> >> x32 doesn't support 64bit relocation, like R_X86_64_64. > > This being a self-fulfilling assertion, because you decided > to disable that relocation. It *could* be supported. Easily. > There is no reason to have it since x32 is a 32bit environment. I don't want/need this relocation in x32.
On Thu, Jul 21, 2011 at 6:42 PM, Richard Henderson <rth@redhat.com> wrote: > On 07/21/2011 09:28 AM, H.J. Lu wrote: >> On Thu, Jul 21, 2011 at 9:23 AM, Richard Henderson <rth@redhat.com> wrote: >>> On 07/21/2011 09:20 AM, H.J. Lu wrote: >>>> ".quad symbol" isn't really valid for 32bit. >>> >>> Why not? We certainly know what value to put there. >>> >> >> x32 doesn't support 64bit relocation, like R_X86_64_64. > > This being a self-fulfilling assertion, because you decided > to disable that relocation. It *could* be supported. Easily. IMO, it is OK to disable 64bit relocations, and that compiler is at fault here. Consider that something gets written to the d field (see example of PR49798). Reading a pointer from *m fileld in DImode, we will get non-zero bits in high 32bits of a pointer. We have to access the pointer in SImode. Uros.
On 07/21/2011 10:39 AM, Uros Bizjak wrote: > IMO, it is OK to disable 64bit relocations, and that compiler is at > fault here. Consider that something gets written to the d field (see > example of PR49798). Reading a pointer from *m fileld in DImode, we > will get non-zero bits in high 32bits of a pointer. We have to access > the pointer in SImode. IMO this is only tangentially related to the compiler at all. I think disabling 64bit relocations is unnecessarily awkward for assembly programmers. Consider when one wants to build jump tables. You either have to have a register available for zero-extension, or do the .word x, 0 thing. Which I think is being silly and arbitrary; the assembler damned well knows what I want when I write .quad x. r~
On Thu, Jul 21, 2011 at 11:02 AM, Richard Henderson <rth@redhat.com> wrote: > On 07/21/2011 10:39 AM, Uros Bizjak wrote: >> IMO, it is OK to disable 64bit relocations, and that compiler is at >> fault here. Consider that something gets written to the d field (see >> example of PR49798). Reading a pointer from *m fileld in DImode, we >> will get non-zero bits in high 32bits of a pointer. We have to access >> the pointer in SImode. > > IMO this is only tangentially related to the compiler at all. > I think disabling 64bit relocations is unnecessarily awkward > for assembly programmers. > > Consider when one wants to build jump tables. You either have to > have a register available for zero-extension, or do the .word x, 0 > thing. Which I think is being silly and arbitrary; the assembler > damned well knows what I want when I write .quad x. > It will make it harder to identify issues where you do want to array of pointers when porting x86-64 assembly codes to x32.
On Thu, Jul 21, 2011 at 10:30 AM, Uros Bizjak <ubizjak@gmail.com> wrote: > On Thu, Jul 21, 2011 at 7:24 PM, H.J. Lu <hjl.tools@gmail.com> wrote: >> On Thu, Jul 21, 2011 at 10:04 AM, Uros Bizjak <ubizjak@gmail.com> wrote: >>> On Thu, Jul 21, 2011 at 6:28 PM, H.J. Lu <hjl.tools@gmail.com> wrote: >>> >>>>>> ".quad symbol" isn't really valid for 32bit. >>>>> >>>>> Why not? We certainly know what value to put there. >>>>> >>>> >>>> x32 doesn't support 64bit relocation, like R_X86_64_64. >>>> In many causes, generate >>>> >>>> .long symbol >>>> .long 0 >>>> >>>> for ".quad symbol" is wrong. Please see: >>>> >>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47446 >>>> >>>> for some examples. >>> >>> Please also see: >>> >>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49798#c12 >>> >>> on why I think this is middle-end/tree-optimization issue. >>> >> >> I still think it is a backend issue. > > /* Represents viewing something of one type as being of a second type. > This corresponds to an "Unchecked Conversion" in Ada and roughly to > the idiom *(type2 *)&X in C. The only operand is the value to be > viewed as being of another type. **It is undefined if the type of the > input and of the expression have different sizes.** > > ... > DEFTREECODE (VIEW_CONVERT_EXPR, "view_convert_expr", tcc_reference, 1) > > We have: > > <bb 2>: > D.2709_8 = VIEW_CONVERT_EXPR<double>(&xxxx); > D.2702_1 = u.d; > D.2704_3 = D.2702_1 == D.2709_8; > D.2701_4 = (int) D.2704_3; > return D.2701_4; > > Where > > sizeof (double) = 64 > sizeof (ptr_type) = 32. > We may have 2 issues, one in middle-end, which generates undefined VIEW_CONVERT_EXPR and one in back-end, which fails to zero-extend symbol address.
On Thu, Jul 21, 2011 at 10:30 AM, Uros Bizjak <ubizjak@gmail.com> wrote: > On Thu, Jul 21, 2011 at 7:24 PM, H.J. Lu <hjl.tools@gmail.com> wrote: >> On Thu, Jul 21, 2011 at 10:04 AM, Uros Bizjak <ubizjak@gmail.com> wrote: >>> On Thu, Jul 21, 2011 at 6:28 PM, H.J. Lu <hjl.tools@gmail.com> wrote: >>> >>>>>> ".quad symbol" isn't really valid for 32bit. >>>>> >>>>> Why not? We certainly know what value to put there. >>>>> >>>> >>>> x32 doesn't support 64bit relocation, like R_X86_64_64. >>>> In many causes, generate >>>> >>>> .long symbol >>>> .long 0 >>>> >>>> for ".quad symbol" is wrong. Please see: >>>> >>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47446 >>>> >>>> for some examples. >>> >>> Please also see: >>> >>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49798#c12 >>> >>> on why I think this is middle-end/tree-optimization issue. >>> >> >> I still think it is a backend issue. > > /* Represents viewing something of one type as being of a second type. > This corresponds to an "Unchecked Conversion" in Ada and roughly to > the idiom *(type2 *)&X in C. The only operand is the value to be > viewed as being of another type. **It is undefined if the type of the > input and of the expression have different sizes.** > > ... > DEFTREECODE (VIEW_CONVERT_EXPR, "view_convert_expr", tcc_reference, 1) > > We have: > > <bb 2>: > D.2709_8 = VIEW_CONVERT_EXPR<double>(&xxxx); > D.2702_1 = u.d; > D.2704_3 = D.2702_1 == D.2709_8; > D.2701_4 = (int) D.2704_3; > return D.2701_4; > > Where > > sizeof (double) = 64 > sizeof (ptr_type) = 32. > Are you sure that you used -mx32? I couldn't reproduce it. It looks like an x86 backend bug to me.
On Thu, Jul 21, 2011 at 10:00 PM, H.J. Lu <hjl.tools@gmail.com> wrote: >> /* Represents viewing something of one type as being of a second type. >> This corresponds to an "Unchecked Conversion" in Ada and roughly to >> the idiom *(type2 *)&X in C. The only operand is the value to be >> viewed as being of another type. **It is undefined if the type of the >> input and of the expression have different sizes.** >> >> ... >> DEFTREECODE (VIEW_CONVERT_EXPR, "view_convert_expr", tcc_reference, 1) >> >> We have: >> >> <bb 2>: >> D.2709_8 = VIEW_CONVERT_EXPR<double>(&xxxx); >> D.2702_1 = u.d; >> D.2704_3 = D.2702_1 == D.2709_8; >> D.2701_4 = (int) D.2704_3; >> return D.2701_4; >> >> Where >> >> sizeof (double) = 64 >> sizeof (ptr_type) = 32. >> > > Are you sure that you used -mx32? I couldn't reproduce it. > It looks like an x86 backend bug to me. Hm, can't reproduce it anymore... x32 -O2 looks OK: <bb 2>: v = {}; v.m = &xxxx; D.2702_1 = u.d; D.2703_2 = v.d; D.2704_3 = D.2702_1 == D.2703_2; D.2701_4 = (int) D.2704_3; return D.2701_4; } Expand generates: (insn 8 6 9 (set (reg:SI 68) (symbol_ref:SI ("xxxx") [flags 0x40] <var_decl 0x7fccc360b140 xxxx>)) p r49798.c:12 -1 (nil)) (insn 9 8 10 (set (reg:DI 67) (zero_extend:DI (reg:SI 68))) pr49798.c:12 -1 (nil)) I don't know if this is OK to be transformed to DImode load. Uros.
On Thu, Jul 21, 2011 at 1:17 PM, Uros Bizjak <ubizjak@gmail.com> wrote: > On Thu, Jul 21, 2011 at 10:00 PM, H.J. Lu <hjl.tools@gmail.com> wrote: > >>> /* Represents viewing something of one type as being of a second type. >>> This corresponds to an "Unchecked Conversion" in Ada and roughly to >>> the idiom *(type2 *)&X in C. The only operand is the value to be >>> viewed as being of another type. **It is undefined if the type of the >>> input and of the expression have different sizes.** >>> >>> ... >>> DEFTREECODE (VIEW_CONVERT_EXPR, "view_convert_expr", tcc_reference, 1) >>> >>> We have: >>> >>> <bb 2>: >>> D.2709_8 = VIEW_CONVERT_EXPR<double>(&xxxx); >>> D.2702_1 = u.d; >>> D.2704_3 = D.2702_1 == D.2709_8; >>> D.2701_4 = (int) D.2704_3; >>> return D.2701_4; >>> >>> Where >>> >>> sizeof (double) = 64 >>> sizeof (ptr_type) = 32. >>> >> >> Are you sure that you used -mx32? I couldn't reproduce it. >> It looks like an x86 backend bug to me. > > Hm, can't reproduce it anymore... x32 -O2 looks OK: > > <bb 2>: > v = {}; > v.m = &xxxx; > D.2702_1 = u.d; > D.2703_2 = v.d; > D.2704_3 = D.2702_1 == D.2703_2; > D.2701_4 = (int) D.2704_3; > return D.2701_4; > > } > > Expand generates: > > (insn 8 6 9 (set (reg:SI 68) > (symbol_ref:SI ("xxxx") [flags 0x40] <var_decl 0x7fccc360b140 xxxx>)) p > r49798.c:12 -1 > (nil)) > > (insn 9 8 10 (set (reg:DI 67) > (zero_extend:DI (reg:SI 68))) pr49798.c:12 -1 > (nil)) > > I don't know if this is OK to be transformed to DImode load. > I believe it is valid.
On Thu, Jul 21, 2011 at 10:22 PM, H.J. Lu <hjl.tools@gmail.com> wrote: >> Expand generates: >> >> (insn 8 6 9 (set (reg:SI 68) >> (symbol_ref:SI ("xxxx") [flags 0x40] <var_decl 0x7fccc360b140 xxxx>)) p >> r49798.c:12 -1 >> (nil)) >> >> (insn 9 8 10 (set (reg:DI 67) >> (zero_extend:DI (reg:SI 68))) pr49798.c:12 -1 >> (nil)) >> >> I don't know if this is OK to be transformed to DImode load. >> > > I believe it is valid. How is this situation handled in other targets? I don't see that any of other ptr_mode != Pmode targets define TARGET_ASM_INTEGER in the way you propose. Uros.
On Thu, Jul 21, 2011 at 2:00 PM, Uros Bizjak <ubizjak@gmail.com> wrote: > On Thu, Jul 21, 2011 at 10:22 PM, H.J. Lu <hjl.tools@gmail.com> wrote: > >>> Expand generates: >>> >>> (insn 8 6 9 (set (reg:SI 68) >>> (symbol_ref:SI ("xxxx") [flags 0x40] <var_decl 0x7fccc360b140 xxxx>)) p >>> r49798.c:12 -1 >>> (nil)) >>> >>> (insn 9 8 10 (set (reg:DI 67) >>> (zero_extend:DI (reg:SI 68))) pr49798.c:12 -1 >>> (nil)) >>> >>> I don't know if this is OK to be transformed to DImode load. >>> >> >> I believe it is valid. > > How is this situation handled in other targets? I don't see that any > of other ptr_mode != Pmode targets define TARGET_ASM_INTEGER in the > way you propose. > Other ptr_mode != Pmode targets don't run into this issue since they have different instruction sets. X32 may be the first (only) target for this problem.
On Thu, Jul 21, 2011 at 11:02 AM, Richard Henderson <rth@redhat.com> wrote: > On 07/21/2011 10:39 AM, Uros Bizjak wrote: >> IMO, it is OK to disable 64bit relocations, and that compiler is at >> fault here. Consider that something gets written to the d field (see >> example of PR49798). Reading a pointer from *m fileld in DImode, we >> will get non-zero bits in high 32bits of a pointer. We have to access >> the pointer in SImode. > > IMO this is only tangentially related to the compiler at all. > I think disabling 64bit relocations is unnecessarily awkward > for assembly programmers. > > Consider when one wants to build jump tables. You either have to > have a register available for zero-extension, or do the .word x, 0 > thing. Which I think is being silly and arbitrary; the assembler > damned well knows what I want when I write .quad x. > I withdrew this patch. Assembler will accept ".quad foo" and zero-extend it to 8 byte.
On Thu, Jul 21, 2011 at 7:30 PM, Uros Bizjak <ubizjak@gmail.com> wrote: > On Thu, Jul 21, 2011 at 7:24 PM, H.J. Lu <hjl.tools@gmail.com> wrote: >> On Thu, Jul 21, 2011 at 10:04 AM, Uros Bizjak <ubizjak@gmail.com> wrote: >>> On Thu, Jul 21, 2011 at 6:28 PM, H.J. Lu <hjl.tools@gmail.com> wrote: >>> >>>>>> ".quad symbol" isn't really valid for 32bit. >>>>> >>>>> Why not? We certainly know what value to put there. >>>>> >>>> >>>> x32 doesn't support 64bit relocation, like R_X86_64_64. >>>> In many causes, generate >>>> >>>> .long symbol >>>> .long 0 >>>> >>>> for ".quad symbol" is wrong. Please see: >>>> >>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47446 >>>> >>>> for some examples. >>> >>> Please also see: >>> >>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49798#c12 >>> >>> on why I think this is middle-end/tree-optimization issue. >>> >> >> I still think it is a backend issue. > > /* Represents viewing something of one type as being of a second type. > This corresponds to an "Unchecked Conversion" in Ada and roughly to > the idiom *(type2 *)&X in C. The only operand is the value to be > viewed as being of another type. **It is undefined if the type of the > input and of the expression have different sizes.** > > ... > DEFTREECODE (VIEW_CONVERT_EXPR, "view_convert_expr", tcc_reference, 1) > > We have: > > <bb 2>: > D.2709_8 = VIEW_CONVERT_EXPR<double>(&xxxx); > D.2702_1 = u.d; > D.2704_3 = D.2702_1 == D.2709_8; > D.2701_4 = (int) D.2704_3; > return D.2701_4; > > Where > > sizeof (double) = 64 > sizeof (ptr_type) = 32. That's certainly bogus. Richard. > Uros. >
2011-07-21 H.J. Lu <hongjiu.lu@intel.com> PR target/49798 * config/i386/i386.c (ix86_asm_integer): New. (TARGET_ASM_INTEGER): Likewise. diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c index a60085c..d72edff 100644 --- a/gcc/config/i386/i386.c +++ b/gcc/config/i386/i386.c @@ -14289,6 +14289,24 @@ i386_asm_output_addr_const_extra (FILE *file, rtx x) return true; } + +/* Implementation of TARGET_ASM_INTEGER. */ + +static bool +ix86_asm_integer (rtx x, unsigned int size, int aligned_p) +{ + if (TARGET_X32 + && size == 8 + && !CONST_INT_P (x) + && !CONST_DOUBLE_P (x)) + { + /* Zero-extend symbol address to 64bit. */ + default_assemble_integer (x, 4, aligned_p); + default_assemble_integer (const0_rtx, 4, aligned_p); + return true; + } + return default_assemble_integer (x, size, aligned_p); +} /* Split one or more double-mode RTL references into pairs of half-mode references. The RTL can be REG, offsettable MEM, integer constant, or @@ -34892,6 +34910,8 @@ ix86_autovectorize_vector_sizes (void) #define TARGET_ASM_UNALIGNED_SI_OP TARGET_ASM_ALIGNED_SI_OP #undef TARGET_ASM_UNALIGNED_DI_OP #define TARGET_ASM_UNALIGNED_DI_OP TARGET_ASM_ALIGNED_DI_OP +#undef TARGET_ASM_INTEGER +#define TARGET_ASM_INTEGER ix86_asm_integer #undef TARGET_PRINT_OPERAND #define TARGET_PRINT_OPERAND ix86_print_operand