[m-rev.] for review: function trailing and aligned addresses

[Mark Brown]

On 18-Jan-2008, Julien Fischer <juliensf at csse.unimelb.edu.au> wrote:
> Mark had a similar problem with G12's trail module a few months ago.
> I think we should modify the compiler so that in trailing grades it always
> enabled gcc's -falign-functions option.

I agree.  I can't imagine that this option would cause anyone any grief.
Make sure it is the `-falign-functions=bytes' version though -- the version
that doesn't specify the alignment size does not do the obvious thing!
The default size is assembler dependent (and on my Ubuntu system is 1, IIRC).

Also, I think the test in MR_USE_TAGGED_TRAIL is not quite right.  It tests
whether it is safe to use tagged trail entries by looking at whether *mercury*
data has enough tag bits.  But the trailing interface is C, so really the
test should be whether we expect there to be enough tag bits in C pointers.

Note that the same problem occurs with value trail entries -- the user needs
to ensure that their data structures are aligned properly.

> Alternatively we could add
> an extra word at the beginning of function trail entries to store the
> tag - this would have the advantage that users would not need to worry
> about what is a fairly obscure point.

Perhaps a configuration option to make it easier to disable the tagged
trail optimization?

>
> Estimated hours taken: 1
> Branches: main
>
> Document a subtle problem that can occur with function trailing.
>
> Fix some failing test cases in the .tr.ll_debug grades.
>
> doc/reference_manual.texi:
> 	Document that the addresses of the C functions used in function trailing
> 	need to be word aligned.
>
> tests/trailing/Mercury.options:
> 	Fix the failure of some trailing test cases in .ll_debug grades by 
> ensuring
> 	that C functions are aligned on 64-bit boundaries.  (The set of C
> 	optimisations implied by the .ll_debug grades disable the 
> -falign-functions
> 	optimisation.)
>
> Julien.
>
> Index: doc/reference_manual.texi
> ===================================================================
> RCS file: 
> /home/mercury/mercury1/repository/mercury/doc/reference_manual.texi,v
> retrieving revision 1.415
> diff -u -r1.415 reference_manual.texi
> --- doc/reference_manual.texi	14 Jan 2008 00:08:02 -0000	1.415
> +++ doc/reference_manual.texi	18 Jan 2008 03:21:07 -0000
> @@ -8922,6 +8922,10 @@
>  If it is called with anything else (such as @samp{MR_gc}),
>  then it should probably abort execution with an error message.
>
> +Note that in the current implementation the address of the C function

Is it really just a limitation of the current implementation, or is it
actually how we intend the interface to be?  If it's the former, we can
remove the limitation by defining MR_USE_TAGGED_TRAIL to be 0.  But I
think it should be the latter, so I think you should remove "Note that
in the current implementation" from the start of that sentence.

> +passed as the first argument of @code{MR_trail_function()} must be word
> +aligned.
> +
>  @node Delayed goals and floundering
>  @subsection Delayed goals and floundering
>

I think it would be good to add something similar to the value trailing
section too.  Namely, that the MR_Word * addresses must be word aligned.

Otherwise this is okay.

Cheers,
Mark.
--------------------------------------------------------------------------
mercury-reviews mailing list
Post messages to:       mercury-reviews at csse.unimelb.edu.au
Administrative Queries: owner-mercury-reviews at csse.unimelb.edu.au
Subscriptions:          mercury-reviews-request at csse.unimelb.edu.au
--------------------------------------------------------------------------