Can't use SImode as Pmode for x32

Can't use SImode as Pmode for x32

[H.J. Lu]

On Wed, Mar 16, 2011 at 4:28 PM, Jakub Jelinek <jakub@redhat.com> wrote:
> On Wed, Mar 16, 2011 at 03:38:25PM -0700, H.J. Lu wrote:
>
> IMNSHO you really should reconsider using Pmode != ptr_mode for your port.

Hi Jakub,

I created hjl/x32/Pmode/master branch at

http://git.kernel.org/?p=devel/gcc/hjl/x86.git;a=summary

It will require very extensive changes to x86 backend since stack pointer
and frame pointer are really in DImode for x32 as x32 process runs in
64bit mode. If you can make it to work, please let me know.

Thanks.


-- 
H.J.

Re: Can't use SImode as Pmode for x32

[Richard Henderson]

On 03/17/2011 03:28 PM, H.J. Lu wrote:
> It will require very extensive changes to x86 backend since stack pointer
> and frame pointer are really in DImode for x32 as x32 process runs in
> 64bit mode. If you can make it to work, please let me know.

Yes, the stack pointer uses all 64 bits for e.g. push/pop/call.  But so
what?  Given that our 32-bit move insns also implicitly zero-extend, I
don't see that we need to actually expose the fact of the 64-bit RSP to
the rest of the compiler.


r~

Re: Can't use SImode as Pmode for x32

[H.J. Lu]

On Fri, Mar 18, 2011 at 2:03 PM, Richard Henderson <rth@redhat.com> wrote:
> On 03/17/2011 03:28 PM, H.J. Lu wrote:
>> It will require very extensive changes to x86 backend since stack pointer
>> and frame pointer are really in DImode for x32 as x32 process runs in
>> 64bit mode. If you can make it to work, please let me know.
>
> Yes, the stack pointer uses all 64 bits for e.g. push/pop/call.  But so
> what?  Given that our 32-bit move insns also implicitly zero-extend, I
> don't see that we need to actually expose the fact of the 64-bit RSP to
> the rest of the compiler.
>

X86 backend uses Pmode for hardware pointer size. Changes
it to 32bit for x32, which is really 64bit process, breaks many
assumptions of x86 backend. push/pop/call is just the tip of
the iceberg.


-- 
H.J.

Re: Can't use SImode as Pmode for x32

[Richard Henderson]

On 03/18/2011 02:56 PM, H.J. Lu wrote:
> X86 backend uses Pmode for hardware pointer size. Changes
> it to 32bit for x32, which is really 64bit process, breaks many
> assumptions of x86 backend. push/pop/call is just the tip of
> the iceberg.

Please enumerate "many assumptions".  I can't think of any off
the top of my head.


r~

Re: Can't use SImode as Pmode for x32

[H.J. Lu]

On Fri, Mar 18, 2011 at 3:18 PM, Richard Henderson <rth@redhat.com> wrote:
> On 03/18/2011 02:56 PM, H.J. Lu wrote:
>> X86 backend uses Pmode for hardware pointer size. Changes
>> it to 32bit for x32, which is really 64bit process, breaks many
>> assumptions of x86 backend. push/pop/call is just the tip of
>> the iceberg.
>
> Please enumerate "many assumptions".  I can't think of any off
> the top of my head.
>

I don't have a complete list.  gen_push is one of them:

static rtx
gen_push (rtx arg)
{
  struct machine_function *m = cfun->machine;

  if (m->fs.cfa_reg == stack_pointer_rtx)
    m->fs.cfa_offset += UNITS_PER_WORD;
  m->fs.sp_offset += UNITS_PER_WORD;

  return gen_rtx_SET (VOIDmode,
                      gen_rtx_MEM (Pmode,
                                   gen_rtx_PRE_DEC (Pmode,
                                                    stack_pointer_rtx)),
                      arg);
}

You can only push/pup 64bit in hardware 64bit mode.


-- 
H.J.

Re: Can't use SImode as Pmode for x32

[Jakub Jelinek]

On Fri, Mar 18, 2011 at 03:32:45PM -0700, H.J. Lu wrote:
> On Fri, Mar 18, 2011 at 3:18 PM, Richard Henderson <rth@redhat.com> wrote:
> > On 03/18/2011 02:56 PM, H.J. Lu wrote:
> >> X86 backend uses Pmode for hardware pointer size. Changes
> >> it to 32bit for x32, which is really 64bit process, breaks many
> >> assumptions of x86 backend. push/pop/call is just the tip of
> >> the iceberg.
> >
> > Please enumerate "many assumptions".  I can't think of any off
> > the top of my head.
> >
> 
> I don't have a complete list.  gen_push is one of them:
> 
> static rtx
> gen_push (rtx arg)
> {
>   struct machine_function *m = cfun->machine;
> 
>   if (m->fs.cfa_reg == stack_pointer_rtx)
>     m->fs.cfa_offset += UNITS_PER_WORD;
>   m->fs.sp_offset += UNITS_PER_WORD;
> 
>   return gen_rtx_SET (VOIDmode,
>                       gen_rtx_MEM (Pmode,
>                                    gen_rtx_PRE_DEC (Pmode,
>                                                     stack_pointer_rtx)),
>                       arg);
> }
> 
> You can only push/pup 64bit in hardware 64bit mode.

That's still push/pop/call.  And you can certainly use a Pmode (== SImode)
stack_pointer_rtx to describe it too, push/pop reference %rsp just
implicitly.  For the MEM you would just use DImode for x32 in that case,
or for <= 32 bit pushes you could describe it as a SImode MEM with
PRE_MODIFY inside of it.

For addresses, you could use 32-bit regs (i.e. addr32 prefix) by default,
perhaps with machine reorg optimizing away some of the addr32 prefixes when
it can prove the base register is already zero extended, and if there is no
added or very small one.

	Jakub

Re: Can't use SImode as Pmode for x32

[Richard Henderson]

On 03/18/2011 03:32 PM, H.J. Lu wrote:
> I don't have a complete list.  gen_push is one of them:
...
> You can only push/pup 64bit in hardware 64bit mode.

Ok, seems an easy enough place to use word_mode instead.


r~

Re: Can't use SImode as Pmode for x32

[H.J. Lu]

On Fri, Mar 18, 2011 at 3:42 PM, Jakub Jelinek <jakub@redhat.com> wrote:
> On Fri, Mar 18, 2011 at 03:32:45PM -0700, H.J. Lu wrote:
>> On Fri, Mar 18, 2011 at 3:18 PM, Richard Henderson <rth@redhat.com> wrote:
>> > On 03/18/2011 02:56 PM, H.J. Lu wrote:
>> >> X86 backend uses Pmode for hardware pointer size. Changes
>> >> it to 32bit for x32, which is really 64bit process, breaks many
>> >> assumptions of x86 backend. push/pop/call is just the tip of
>> >> the iceberg.
>> >
>> > Please enumerate "many assumptions".  I can't think of any off
>> > the top of my head.
>> >
>>
>> I don't have a complete list.  gen_push is one of them:
>>
>> static rtx
>> gen_push (rtx arg)
>> {
>>   struct machine_function *m = cfun->machine;
>>
>>   if (m->fs.cfa_reg == stack_pointer_rtx)
>>     m->fs.cfa_offset += UNITS_PER_WORD;
>>   m->fs.sp_offset += UNITS_PER_WORD;
>>
>>   return gen_rtx_SET (VOIDmode,
>>                       gen_rtx_MEM (Pmode,
>>                                    gen_rtx_PRE_DEC (Pmode,
>>                                                     stack_pointer_rtx)),
>>                       arg);
>> }
>>
>> You can only push/pup 64bit in hardware 64bit mode.
>
> That's still push/pop/call.  And you can certainly use a Pmode (== SImode)
> stack_pointer_rtx to describe it too, push/pop reference %rsp just
> implicitly.  For the MEM you would just use DImode for x32 in that case,
> or for <= 32 bit pushes you could describe it as a SImode MEM with
> PRE_MODIFY inside of it.

Because TARGET_MEM_REF only works on ptr_mode:

http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00655.html

x32 accepts (%eax,%ebx,4).

> For addresses, you could use 32-bit regs (i.e. addr32 prefix) by default,
> perhaps with machine reorg optimizing away some of the addr32 prefixes when
> it can prove the base register is already zero extended, and if there is no
> added or very small one.

You can change 32bit registers in memory address to 64bit only if there is
no index register.

I will try ptr_mode == SImode and report any new problems.

Thanks.


-- 
H.J.

Re: Can't use SImode as Pmode for x32

[H.J. Lu]

On Fri, Mar 18, 2011 at 3:42 PM, Jakub Jelinek <jakub@redhat.com> wrote:
> On Fri, Mar 18, 2011 at 03:32:45PM -0700, H.J. Lu wrote:
>> On Fri, Mar 18, 2011 at 3:18 PM, Richard Henderson <rth@redhat.com> wrote:
>> > On 03/18/2011 02:56 PM, H.J. Lu wrote:
>> >> X86 backend uses Pmode for hardware pointer size. Changes
>> >> it to 32bit for x32, which is really 64bit process, breaks many
>> >> assumptions of x86 backend. push/pop/call is just the tip of
>> >> the iceberg.
>> >
>> > Please enumerate "many assumptions".  I can't think of any off
>> > the top of my head.
>> >
>>
>> I don't have a complete list.  gen_push is one of them:
>>
>> static rtx
>> gen_push (rtx arg)
>> {
>>   struct machine_function *m = cfun->machine;
>>
>>   if (m->fs.cfa_reg == stack_pointer_rtx)
>>     m->fs.cfa_offset += UNITS_PER_WORD;
>>   m->fs.sp_offset += UNITS_PER_WORD;
>>
>>   return gen_rtx_SET (VOIDmode,
>>                       gen_rtx_MEM (Pmode,
>>                                    gen_rtx_PRE_DEC (Pmode,
>>                                                     stack_pointer_rtx)),
>>                       arg);
>> }
>>
>> You can only push/pup 64bit in hardware 64bit mode.
>
> That's still push/pop/call.  And you can certainly use a Pmode (== SImode)
> stack_pointer_rtx to describe it too, push/pop reference %rsp just
> implicitly.  For the MEM you would just use DImode for x32 in that case,
> or for <= 32 bit pushes you could describe it as a SImode MEM with
> PRE_MODIFY inside of it.
>

Operations on stack and frame pointers, like push/pop, require stack
and frame pointers in DImode.  Even if I use word_mode in gen_push
and gen_pop, I got

[hjl@gnu-6 pmode-1]$ cat x.i
extern void abort (void) __attribute__ ((__nothrow__)) __attribute__
((__noreturn__));
typedef int DItype __attribute__ ((mode (DI)));
typedef unsigned int UDItype __attribute__ ((mode (DI)));
void
foo (DItype a, DItype b)
{
  const DItype w = (UDItype) a + (UDItype) b;
  if (w < a)
    abort ();
}
[hjl@gnu-6 pmode-1]$ make
/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/ -S -o x.s -mx32
x.i
x.i: In function \u2018foo\u2019:
x.i:10:1: error: unrecognizable insn:
(insn/f 22 5 23 2 (set (mem:SI (pre_dec:DI (reg/f:SI 7 sp)) [0 S4 A8])
        (reg/f:SI 6 bp)) x.i:6 -1
     (nil))
x.i:10:1: internal compiler error: in insn_default_length, at
config/i386/i386.md:600
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make: *** [x.s] Error 1
[hjl@gnu-6 pmode-1]$


-- 
H.J.

Re: Can't use SImode as Pmode for x32

[Richard Henderson]

On 03/19/2011 08:46 AM, H.J. Lu wrote:
> Operations on stack and frame pointers, like push/pop, require stack
> and frame pointers in DImode.  Even if I use word_mode in gen_push
> and gen_pop, I got

No they don't.  Not really.  Assuming the stack and frame pointer are
properly zero extended, and no one tries to place a stack frame across
null, then you can also represent it by an SImode operation.

> x.i:10:1: error: unrecognizable insn:
> (insn/f 22 5 23 2 (set (mem:SI (pre_dec:DI (reg/f:SI 7 sp)) [0 S4 A8])
>         (reg/f:SI 6 bp)) x.i:6 -1
>      (nil))

Well, gee, that merely means a pattern needs to be adjusted.


r~

Re: Can't use SImode as Pmode for x32

[H.J. Lu]

On Wed, Mar 23, 2011 at 12:06 PM, Richard Henderson <rth@redhat.com> wrote:
> On 03/19/2011 08:46 AM, H.J. Lu wrote:
>> Operations on stack and frame pointers, like push/pop, require stack
>> and frame pointers in DImode.  Even if I use word_mode in gen_push
>> and gen_pop, I got
>
> No they don't.  Not really.  Assuming the stack and frame pointer are
> properly zero extended, and no one tries to place a stack frame across
> null, then you can also represent it by an SImode operation.
>
>> x.i:10:1: error: unrecognizable insn:
>> (insn/f 22 5 23 2 (set (mem:SI (pre_dec:DI (reg/f:SI 7 sp)) [0 S4 A8])
>>         (reg/f:SI 6 bp)) x.i:6 -1
>>      (nil))
>
> Well, gee, that merely means a pattern needs to be adjusted.
>
>

Are you suggesting that we should say that SP and BP are 32bits so
that x32 has 16 integer registers, 14 are 64 bites and 2 are 32 bits?
How will it work with RA? Can I use BP for integer operations?

-- 
H.J.

Re: Can't use SImode as Pmode for x32

[Richard Henderson]

On 03/23/2011 08:40 PM, H.J. Lu wrote:
> Are you suggesting that we should say that SP and BP are 32bits so
> that x32 has 16 integer registers, 14 are 64 bites and 2 are 32 bits?

No, merely that push/pop are valid with (reg:SI 7 sp).

r~