[m-rev.] for review: delete .regparm and .picreg

[Julien Fischer]

Hi Zoltan,

On Thu, 25 Feb 2016, Zoltan Somogyi wrote:

> Remove the .regparm and .picreg grade components.
> 
> For picreg, this is only the first half of the change; it deletes code
> that generates references to this grade component. When this diff has been
> installed on all our machines, will come the second half, which will delete
> the code that understands references to picreg. The delay is needed because
> your current installed compiler is still generating such references.

...

> scripts/Mercury.config.bootstrap.in:
> scripts/Mercury.config.in:
>     Remove code that transmitted the value of EXT_FOR_LINK_WITH_PIC_OBJECTS
>     to the compiler via the --link-with-pic-object-file-extension option.
> 
> compiler/options.m:
>     Keep the --link-with-pic-object-file-extension and --pic-reg options,
>     but mark them for deletion in the second half of this change.
>
>     place the code that accepts picreg grade components,

s/place/Replace/ ?

>     but make them do nothing. Mark such do-nothing code so that
>     it can be deleted when this first-half diff has been bootstrapped.
>

...

> diff --git a/runtime/mercury_grade.h b/runtime/mercury_grade.h
> index 34f24a9..9a57fa4 100644
> --- a/runtime/mercury_grade.h
> +++ b/runtime/mercury_grade.h
> @@ -351,6 +351,23 @@
>  ** Part 12 (i.e. MR_NEW_MERCURYFILE_STRUCT) can't be set
>  ** by the `--grade' option; it is intended to be set by the configure script
>  ** at configuration time. So we don't include it in the grade option string.
> +**
> +** Part 13 used to record the absence/presence of the .regparm grade component
> +** with MR_HIGHLEVEL_CODE, and the absence/presence of the .picreg grade
> +** component for !MR_HIGHLEVEL_CODE and MR_USE_GCC_GLOBAL_REGISTERS.
> +** Neither is in use anymore.
> +**
> +** The .regparm part specified an optimized calling convention of 32-bit x86
> +** machines, which turns out to be a pessimizing calling convention on x86/64.
> +**
> +** Once upon a time, on x86 machines with MR_USE_GCC_GLOBAL_REGISTERS,
> +** we reserved three global registers with if we could, but had to be content

Delete "with".

> +** with two if we were generating position independent code, since PIC needed
> +** a register for itself. However, the difference caused problems in linking
> +** object files compiled with different numbers of global registers reserved,
> +** and gcc bugs kept generating crashes with three reserved registers,
> +** so we now always reserve only two global registers. Therefore the
> +** distinction that .picreg used to record has vanished.
>  */

...

> diff --git a/runtime/mercury_std.h b/runtime/mercury_std.h
> index d2fb5b5..31d1464 100644
> --- a/runtime/mercury_std.h
> +++ b/runtime/mercury_std.h
> @@ -241,27 +241,16 @@ typedef	char		MR_small_bool;
>  ** calling convention.
>  **
>  ** If MR_USE_REGPARM is defined, and we're using gcc on x86,

Why leave the reference to MR_USE_REGPARM here?  This comment should
document what the intended purpose of the MR_CALL macro is.

> -** then we use a non-standard but more efficient calling
> +** then we USED to use a non-standard but more efficient calling
>  ** convention that passes parameters in registers.
> -** Otherwise we just use the default C calling convention.
> +** Otherwise we just used the default C calling convention.
>  **
> -** Any changes here (e.g. adding additional calling conventions,
> -** or adding support for other C compilers or other processors)
> -** should be reflected in the mangled grade name produced by
> -** runtime/mercury_grade.h.
> -**
> -** It might be slightly more efficient to use __regparm__(3) rather than
> -** __regparm__(2), but GCC won't do tail-call optimization for calls via
> -** function pointers if we use __regparm__(3), since there may be no spare
> -** caller-save registers to hold the function pointer.  Tail call
> -** optimization is more likely to be important than squeezing the last 1%
> -** in performance.
> +** However, since 32-bit x86s are rare these days, and this non-standard
> +** calling convention is *slower* on x86/64 platforms than the standard one,
> +** we don't do this anymore.
>  */
> -#if defined(MR_USE_REGPARM) && defined(MR_GNUC) && defined(__i386__)
> -  #define MR_CALL __attribute__((__stdcall__, __regparm__(2)))
> -#else
> -  #define MR_CALL
> -#endif
> +
> +#define MR_CALL

The diff looks fine otherwise.

Julien.