[m-dev.] questions about grades

[Julien Fischer]

Hi Zoltan,

On Wed, 24 Feb 2016, Zoltan Somogyi wrote:

>
> On Tue, 23 Feb 2016 14:21:04 +1100, Paul Bone <paul at bone.id.au> wrote:
>> I think it's fine if this goes away.  As of 2015 MC havn't been doing any
>> new projects in C (where MercuryFile is relevent), and if they recompile an
>> old project with a new Mercury this is just one of the many things that may
>> have changed.  I think the cost of maintaining it is higher than the risk of
>> it breaking something and the cost of that breakage.
>
> Actually, I haven't seen any "cost of maintaining it" until this email thread.
>
> Thanks for all your replies; here are my proposals about what to do
> about these grade components, and some new questions.
>
> Zoltan.
>
> -------------------------------------------------------------
>
> I propose that we eliminate the .regparm grade component.

Agreed.

> -------------------------------------------------------------
>
> Neither .spf nor new mercuryfiles is hard to support, and they may have users,
> so I will implement them in the grade library. If we want to delete them,
> I think we should do so only after asking for objections on mercury-users.
>
> BTW, I checked the overhead of enabling new mercuryfiles on tools/speedtest,
> and it made no meaningful difference: the speed difference was very low down
> in the noise. However, this does not say all that much, since the compiler
> is FAR from I/O bound.

In that case, I propose that we either (1) enable new mercuryfiles by
default or (2) delete them entirely.  Either way, it's not a grade
component issue.

> -------------------------------------------------------------
>
> I looked into MR_PIC_REG, and it seems that this grade component hasn't had
> any effect since 2007. Julien disabled it after we agreed that its cost
> exceeded its benefits. The cost was incessant hassle with gcc bugs arising
> from fact that in grades without picreg, we used to reserve THREE machine
> registers, while with picreg, we reserved only TWO. Since that change,
> we ALWAYS use just two. I don't see gcc developers getting any better at
> respecting reserved registers, and the upside of using three registers
> is so small anyway (in 2007, the log message says it was a 2.2% speedup), 
> I don't see us changing that decision in the foreseeable future. Therefore
> I propose that we just delete this grade component.

Agreed.

> -------------------------------------------------------------
>
> There were some things I forgot to ask about in the earlier email.
>
> Was Ralph's history gc intended to be used in LLDS grades? Do we care?

IIRC, it was intended to be usable with either of the C backends.

> I know we support thread segments in LLDS grades,

Presumably, you mean stack segments there ;-)

> and I know we don't support trailing at all when targeting languages
> other than C.
> Do we support trail segments when targeting high level C?

Yes.  (The mechanism is identical for both C backends.)

Julien.