[m-rev.] for review: making pointer_equal a builtin

[Peter Wang]

On Thu, 27 Nov 2014 20:10:06 +1100 (EST), "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> 
> 
> On Thu, 27 Nov 2014 18:00:30 +1100, Peter Wang <novalazy at gmail.com> wrote:
> 
> > > There was an inline pragma on its definition, but most programs, including
> > > the compiler, are not compiled with the intermodule optimization options
> > > that would allow this to take effect. Making it a builtin gets around this
> > > problem.
> > 
> > Minor point: most programs are compiled without intermodule optimization
> > _during development_.
> 
> I don't know about you, but I don't enable intermodule optimization
> on the compiler even when I install it.

Most users would (necessarily) install from the pregenerated C sources,
which are generated with intermodule optimizations enabled.

> > > +std_binop_to_elds(StdBinOp, EldsBinOp) :-
> > > +    require_complete_switch [StdBinOp]
> > > +    (
> > > +        ( StdBinOp = body
> > > +        ; StdBinOp = array_index(_)
> > > +        ; StdBinOp = unsigned_le
> > > +        ; StdBinOp = float_from_dword       % XXX used to fail IMPLICITLY
> > > +        ; StdBinOp = float_word_bits        % XXX used to fail IMPLICITLY
> > > +        ; StdBinOp = str_cmp                % XXX used to fail IMPLICITLY
> > > +        ; StdBinOp = pointer_equal_conservative % handled in our caller
> > > +        ),
> > > +        fail
> > 
> > That's fine.  None of those ops would be used in the Erlang backend as
> > far as I can tell.  erl_gen_simple_expr would throw an exception if they
> > were used.
> 
> OK, I will remove the XXXs, but I am still troubled by the "as far
> as I can tell". I could also tell that these wouldn't be used during
> a bootcheck, since if they were, the caller of the above predicate
> would have aborted the program. The question is, how could you
> guarantee that they wouldn't be used in ANY program?
> 
> The reason I asked was because I couldn't see how to provide
> such a guarantee. I will think about that later.

The Erlang backend goes from HLDS to ELDS.  We can ignore all instances
of those functors in LLDS- and MLDS-specific modules.  That includes all
the constructions as of now.  It doesn't guarantee that in future the
compiler won't make use of those operations such that it aborts when
targeting Erlang, no.

Peter