(Repost, so it doesn't get lost)

[Here's a binary-chop with an interesting codegen issue. It operates fine with any compiler flags other than -inline which, when applied, will cause an access violation.

Compiler flags for the code listing are -g -O -release -inline]

Here's the code:

        private static int bsearch (short[] array, short match)
        {
                int l, u, m;

                l = -1;
                u = array.length;

                while (l+1 != u)
                      {
                      m = (l + u) / 2;
                      if (array[m] < match)
                          l = m;
                      else
                         u = m;
                      }

               if (u >= array.length || array[u] != match)
                   return -u;
               return u;
        }

        static int lookup (short target)
        {
                short index = bsearch (primes, target);
                if (index < 0)
                    index = -index;

                if (index >= primes.length)
                    index = primes.length - 1;

                return primes[index];
        }

The caller looks like this:

        this (FileBucket bucket, int capacity)
        {
                super (Primes.lookup (capacity));
                <snip>
        }
Taking a closer look, the -inline is inlining an instance of the lookup()
method, but passing invalid arguments to the bsearch() method.

GPFs caused by bogus codegen aside, the lookup() method is a seriously poor candidate for inlining. Perhaps D needs to expose more control over such things?

- Kris

Can you make a fully compilable example, please? The reasons are:
1) frequently the real problem is in the stuff snipped out.
2) it's a fair amount of work to invent the boilerplate needed to compile
it. If you already have it, please leave it in - and I hate doing this only
to find out that (1) was the problem.
3) when done, it makes for a nice addition to the tests I run D through for
every release.

Sure Walter; just download the Mango tree from dsource.org :-)

Seriously though; I'm vaguely concerned that some shortening will cause your -inline algorithm to change strategy. Will give it a shot tomorrow, and send you the resulting code.

BTW, how sensitive are your D hash algorithms to prime numbers? Nada? Some? Seriously so?

- Kris



"Walter" <newshound@digitalmars.com> wrote in message news:c8uup3$303e$1@digitaldaemon.com...
> Can you make a fully compilable example, please? The reasons are:
> 1) frequently the real problem is in the stuff snipped out.
> 2) it's a fair amount of work to invent the boilerplate needed to compile
> it. If you already have it, please leave it in - and I hate doing this
only
> to find out that (1) was the problem.
> 3) when done, it makes for a nice addition to the tests I run D through
for
> every release.
>
>

Here you go Walter:

dmd -O -release -inline primes.d inlineBug.d

(see attached files)

> "Walter" <newshound@digitalmars.com> wrote
> Can you make a fully compilable example, please?

"Kris" <someidiot@earthlink.dot.dot.dot.net> wrote in message news:c8v0mb$1ag$1@digitaldaemon.com...
> BTW, how sensitive are your D hash algorithms to prime numbers? Nada?
Some?
> Seriously so?

??

Thanks. It'll get fixed in the next update.

"Kris" <someidiot@earthlink.dot.dot.dot.net> wrote in message news:c90cmf$28r5$1@digitaldaemon.com...
> Here you go Walter:
>
> dmd -O -release -inline primes.d inlineBug.d
>
> (see attached files)
>
> > "Walter" <newshound@digitalmars.com> wrote
> > Can you make a fully compilable example, please?
>
>
>

I meant, does the .length of an associative array impact the performance of the algorithms? Some hashing algorithms favour prime array-lengths ...

Am I completely off base here?

- Kris

"Walter" <newshound@digitalmars.com> wrote in message news:c9185v$gj6$1@digitaldaemon.com...
>
> "Kris" <someidiot@earthlink.dot.dot.dot.net> wrote in message news:c8v0mb$1ag$1@digitaldaemon.com...
> > BTW, how sensitive are your D hash algorithms to prime numbers? Nada?
> Some?
> > Seriously so?
>
> ??
>
>

"Kris" <someidiot@earthlink.dot.dot.dot.net> wrote in message news:c95knj$1oss$1@digitaldaemon.com...
> I meant, does the .length of an associative array impact the performance
of
> the algorithms? Some hashing algorithms favour prime array-lengths ...
>
> Am I completely off base here?

Most of the time, I doubt you'll notice any difference.

LOL!

The "Am I completely off base here?" and your answer make a much better combination than the original question :-)


"Walter" <newshound@digitalmars.com> wrote in message news:c96dut$2tp8$1@digitaldaemon.com...
>
> "Kris" <someidiot@earthlink.dot.dot.dot.net> wrote in message news:c95knj$1oss$1@digitaldaemon.com...
> > I meant, does the .length of an associative array impact the performance
> of
> > the algorithms? Some hashing algorithms favour prime array-lengths ...
> >
> > Am I completely off base here?
>
> Most of the time, I doubt you'll notice any difference.

Arf! You'll never believe me, but I had intended it to apply to the first sentence, not the last <g>.

"Kris" <someidiot@earthlink.dot.dot.dot.net> wrote in message news:c96f75$309k$1@digitaldaemon.com...
> LOL!
>
> The "Am I completely off base here?" and your answer make a much better combination than the original question :-)
>
>
> "Walter" <newshound@digitalmars.com> wrote in message news:c96dut$2tp8$1@digitaldaemon.com...
> >
> > "Kris" <someidiot@earthlink.dot.dot.dot.net> wrote in message news:c95knj$1oss$1@digitaldaemon.com...
> > > I meant, does the .length of an associative array impact the
performance
> > of
> > > the algorithms? Some hashing algorithms favour prime array-lengths ...
> > >
> > > Am I completely off base here?
> >
> > Most of the time, I doubt you'll notice any difference.
>
>