PATCH: x86_64-pc-mingw32 target for gcc

Richard Henderson rth@redhat.com
Wed Mar 21 18:06:00 GMT 2007


On Wed, Mar 21, 2007 at 10:20:17AM +0100, Kai Tietz wrote:
> >    if (TARGET_64BIT_MS_ABI)
> >      {
> >        ix86_cmodel = CM_SMALL_PIC;
> >        flag_pic = 1;
> >      }
> >    else
> >      ix86_cmodel = flag_pic ? CM_SMALL_PIC : CM_SMALL;
> > 
> > And I think we should discuss the small vs medium thing more; from the
> > discussion, I think the above will probably work for you.
> 
> The small model or even the medium PIC models, have currently a lack by 
> using for a constant address push defined within near objects the wrong 
> address memonics, because the code (at least for dll's) may needs to be 
> rebased.
> E.g: gcc produces currently direct address moves as "movl LC0, si", which 
> isn't rebase save. There are two diffent solutions for that, first is 
> using a large model for it - so it gets movq LC0, rsi -, or using rip 
> based addressing - as "lea (LCO-.+rip), rsi".

Notice that I forced flag_pic to be true.  That will force gcc 
to use rip-relative addressing for these constant addresses.

Please do try to understand what I'm explaining to you.

> > >        /* Use register calling convention for local functions when
> > possible.  */
> > > -      if (!TARGET_64BIT && !user_convention && decl
> > > +      if ((!TARGET_64BIT || TARGET_64BIT_MS_ABI) && !
> > user_convention && decl
> > 
> > TARGET_64BIT_MS_ABI already uses a register calling convention.
> > I don't see the point of this change at all.
> Same as above. I prevent to enter the linux part of calling conventions 
> for this case. A simple short-cut.

No, you didn't.  You *entered* the 32-bit part unnecessarily.
You took a long-cut.

> Likewise.

Likewise.

> As I see from my native gcc, things with calling convention are doing even 
> for floating points very well. ?

I guarantee it's wrong.  Look for instance at example func4 
in the calling convention documentation:

  void func4(__m64 a, __m128 b, struct C c, float d);

You currently generate:

        movq    _c(%rip), %rax
        movq    _b(%rip), %rdx
        movq    $1082130432, %r8
        movq    _a(%rip), %rcx
        movss   LC0(%rip), %xmm2
        movdqa  _b(%rip), %xmm1
        movq    %rax, 32(%rsp)
        movq    _c+8(%rip), %rax
        movq    _a(%rip), %xmm0
        movq    %rax, 40(%rsp)
        movq    _c+16(%rip), %rax
        movq    %rax, 48(%rsp)
        movq    _c+24(%rip), %rax
        movq    %rax, 56(%rsp)
        movq    _c+32(%rip), %rax
        movq    %rax, 64(%rsp)
        call    _func4

All 4 arguments are passed incorrectly.

  (1) a is being passed in rcx and xmm0, instead of just rcx.
  (2) b is being passed (halfway) in rdx, and entirely in xmm1,
      instead it should be passed indirectly as a pointer.
  (3) c is being passed on the stack, instead of indirectly as
      a pointer.
  (4) d is passed in xmm2 instead of xmm3.

I repeat: you should *not* reuse any of the x86-64 unix code.

> > > -      if (get_attr_mode (insn) == MODE_SI)
> > > +      if (get_attr_mode (insn) == MODE_SI && !TARGET_64BIT_MS_ABI)
> > >     return "mov{l}\t{%k1, %k0|%k0, %k1}";
> > 
> > Definitely wrong.  The point here is to use "movl $N, %eax" to 
> > load the 32-bit constant N, reserving movabsq for true 64-bit 
> > constants.
> See above about pic code.

You're still wrong.  The instruction was selected to be SImode,
so therefore an SImode instruction should be used.  

If you think it should be a DImode instruction, then the change
must be to the selection code, and not here.  But I also continue
to beleve that you're wrong about all the pic stuff.

> No, it is defined by default to BITS_PER_WORD, which is in fact a word of 
> type long and not a type of long long as needed.

No, you're confused as to what WORD means.  You'll find that it's

i386.h:		#define UNITS_PER_WORD (TARGET_64BIT ? 8 : 4)
defaults.h:	#define BITS_PER_WORD (BITS_PER_UNIT * UNITS_PER_WORD)

And of course 8 * 8 == 64.

> I got the suggestion to pack the new pragma commands within libcpp, which 
> makes from my opionion sense too. What do you think about that ?

It would certainly make sense to at least have some support for those
pragmas in libcpp, since you might be able to avoid parsing the macro
definitions twice.  You'd be able to push and pop their tokenized forms.

I don't think you should move the actual parsing of the pragma there; 
that should be left in c-pragma.c.


r~



More information about the Gcc-patches mailing list