[M3devel] cg.alloca

[Jay K]

http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c
 
 
I'm sure it is plenty fast, and I could make it faster probably by checking the length first and doing just one strcmp instead of 3, it's just the cleanliness perhaps.. though this is basically what the regular gcc backend does anyway -- map function names to builtins.
 
 
m3_convert_function_to_builtin (tree p)
{
  tree *slot = (tree *)htab_find_slot (builtins, p, NO_INSERT);
  if (slot)
  {
    p = *slot;
  }
  else
  {
    const char *name = IDENTIFIER_POINTER (DECL_NAME (p));
    if (name[0] == 'a' || name[0] == '_')
    {
      if (strcmp(name, "alloca") == 0
        || strcmp(name, "_alloca") == 0
        || strcmp(name, "__builtin_alloca") == 0)
      {
        p = built_in_decls[BUILT_IN_ALLOCA];
      }
    }
  }
  return p;
}
 
 
This might not even be needed -- the backend might do it anyway.
What I was partly doing here though is giving myself flexibility in what string to use -- ie. I thought I might get away with "_alloca" and have it "just work" in m3back, and then do the translation here, rather than in Target.i3 have an Alloca: TEXT -- more target-dependent code.
 
 
Given what I know now about NT/x86 though, this is a lost cause -- the function is "chkstk" and has a custom calling convention, so it won't "just work".
 
 
That is, I can try using __builtin_alloca and try w/o the special casing above.
Special casing in m3back is unavoidable, and what string we use is arguably arbitrary, or arguably should be "_chkstk" -- slight additional target-specificity.
 
 
But heck, I'm also willing to go back to the old scheme for NT/x86 anyway, with the static allocation. Though I probably won't.
 
 
I really need to fix the for i := 0 to 10 do try finally end thing -- to not alloca 10 times.
 
 
 
 - Jay


----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Wed, 12 Jan 2011 15:13:40 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] cg.alloca
>
>
> On Jan 12, 2011, at 3:09 PM, Jay K wrote:
>
> >
> > - Are you ok with the ugly/inefficient strcmp?
>
> Where?
>
> >
> > - And what will be a more significant but still not huge transform in m3back?
> > alloca will translate to chkstk -- an actual function call, but renamed
>
> That's fine. I don't want to complicate m3middle for m3back, which is designed for speed not performance of the resulting code.
>
> >
> > The parameter that was already pushed on the stack will be be poped into eax,
> > whereas with an m3cg operation, it would have been put into eax more directly.
> >
> > The return sequence will probably mov esp into..either eax specifically, or any register..I don't think leaving it in esp is easy enough for m3back to deal with. Again a special case in the general function call/return path.
> >
> >
> > (In reality, the transform is quite significant in m3cc, but it is below where we work.)
>
> Indeed.
>
> >
> >
> > It's a funny thing in general, these "built in functions" that get very special handling and aren't necessarily "functions" (as in "call"/"ret"). Not clear in general to me how to model them.
> >
> >
> > It makes one wonder why add/sub/multiply/div aren't builtin functions?
> > i.e. "everything" could be viewed as a function.
> >
> >
> > - Jay
> >
> >
> > ----------------------------------------
> >> From: hosking at cs.purdue.edu
> >> Date: Wed, 12 Jan 2011 13:34:16 -0500
> >> To: jay.krell at cornell.edu
> >> CC: m3devel at elegosoft.com
> >> Subject: Re: [M3devel] cg.alloca
> >>
> >> No, the atomics can't be because they don't map directly to a gcc builtin, whereas alloca *does*.
> >>
> >> On Jan 12, 2011, at 1:06 PM, Jay K wrote:
> >>
> >>>
> >>> On NT386 the function is _chkstk, number of bytes in eax, return value in esp.
> >>> Notice how in parse.c I had to strcmp for the function name. A little gross, but it does work.
> >>> And C/C++ work that way.
> >>> Notice how you implemented atomics.
> >>>
> >>> I half agree though. It could be a function call even for NT386.
> >>> The atomics could be too.
> >>>
> >>> - Jay
> >>>
> >>> ----------------------------------------
> >>>> From: hosking at cs.purdue.edu
> >>>> Date: Wed, 12 Jan 2011 12:10:02 -0500
> >>>> To: jay.krell at cornell.edu
> >>>> CC: m3devel at elegosoft.com
> >>>> Subject: Re: [M3devel] cg.alloca
> >>>>
> >>>> I don't see the reason for this. If alloca is imported and invoked the gcc backend will happily replace it with inline code.
> >>>>
> >>>>
> >>>> Antony Hosking | Associate Professor | Computer Science | Purdue University
> >>>> 305 N. University Street | West Lafayette | IN 47907 | USA
> >>>> Office +1 765 494 6001 | Mobile +1 765 427 5484
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On Jan 12, 2011, at 2:24 AM, Jay K wrote:
> >>>>
> >>>>>
> >>>>> proposed diff attached
> >>>>>
> >>>>> - Jay
> >>>>>
> >>>>> ----------------------------------------
> >>>>>> From: jay.krell at cornell.edu
> >>>>>> To: m3devel at elegosoft.com
> >>>>>> Date: Wed, 12 Jan 2011 06:28:26 +0000
> >>>>>> Subject: [M3devel] cg.alloca
> >>>>>>
> >>>>>>
> >>>>>> I'd like to make alloca a separate operation in m3cg.
> >>>>>> Instead of a special function name that we check for.
> >>>>>> More like the atomics.
> >>>>>> I know how and can do it myself easily enough.
> >>>>>> ok?
> >>>>>>
> >>>>>>
> >>>>>> (and then I'll fix NT386)
> >>>>>>
> >>>>>>
> >>>>>> - Jay
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
>