[m-dev.] for review: MLDS switch optimization

Fergus Henderson fjh at cs.mu.OZ.AU
Mon Nov 13 15:45:40 AEDT 2000


On 09-Nov-2000, Tyson Dowd <trd at cs.mu.OZ.AU> wrote:
> On 09-Nov-2000, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> > 
> > > > +mlds_output_case_cond(Indent, Context, match_range(Low, High)) -->
> > > > +	% This uses the GNU C extension `case <Low> ... <High>:'.
> > > > +	mlds_indent(Context, Indent),
> > > > +	io__write_string("case "),
> > > > +	mlds_output_rval(Low),
> > > > +	io__write_string(" ... "),
> > > > +	mlds_output_rval(High),
> > > > +	io__write_string(":\n").
> > > 
> > > Isn't this going to cause Pete Ross to thump you when it breaks the
> > > VC++ backend?  
> > > 
> > > Have I missed the bit where you avoid generating this for non GNU C
> > > compilers?  Or is it not used yet?
> > 
> > Currently this is not used, since the MLDS code generator doesn't
> > generate switches with `match_range' cases.  I just put it in to
> > keep the MLDS data structure as general as possible.
> > (Perhaps I'm overdoing the generality here...)
> 
> Probably, but I don't have a big problem with that, just that the output
> code doesn't check for GNU C before it spits out unportable code.

Well, this is documented in mlds.m:

		% Most target languages only allow matching on values;
                % only some (e.g. GNU C) allow matching on ranges.

That documentation is some distance away from the declaration of
`match_range', though, so I'll add some more.

> Since we don't test the VC++ backend very often here, it would be a good
> idea to write the alternate code now, rather than wait until it is used.

I don't plan to have any alternate code there in mlds_to_c.m.  The
idea is that the MLDS code generator will avoid generating `match_range'
case conditions if the back-end doesn't support it, just as it currently
avoids generating switches on strings if the back-end doesn't support them.

I could add an option, and have mlds_to_c.m spit out the gcc-specific
code if the option is set and call error/1 otherwise, but is this
really worthwhile?  I'd probably rather just deleting the `match_range'
alternative.

So, there's three possible actions:

	1. leave as is, but document more clearly that match_range should
	   only be used if the target supports it

	2. add an option `use_gcc_case_ranges', and have mlds_to_c.m
	   call error/1 if this option is not set

	3. delete `match_range' from the MLDS

My first preference is for 1 and my second preference is for 3,
but I'm happy to go with 2 or 3 if you want.

> > For the IL back-end, feel free to handle match_range by just calling
> > error/1.
> 
> I should be able to handle it easily using fall-through.

I wouldn't advise that.  If you do, make sure that you will be able
to handle cases like this one

	long x;
	switch (x) {
		case LONGMIN ... -1:
			foo();
			break;
		case 0:
			bar();
			break;
		case 1 ... LONGMAX:
			baz();
			break;
	}

with reasonable efficiency.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
                                    |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------



More information about the developers mailing list