[m-dev.] questions about grades

[Zoltan Somogyi]

On Wed, 24 Feb 2016 09:23:38 +1100 (AEDT), Julien Fischer <jfischer at opturion.com> wrote:
> > I propose that we eliminate the .regparm grade component.
> 
> Agreed.

Anybody else object?

> > 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.

To make a decision between those two, it would be nice to have some data
on the performance impact on a program that IS I/O bound. Comparing
the new mercuryfile struct with equivalent code using the stream interface.
Does anyone know whether the stream-oriented library modules are a
COMPLETE replacement for new mercuryfile?

> > 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.

OK, I will do this, together with regparm, if there are no objections.

> > 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.

Thanks.
 
> > I know we support thread segments in LLDS grades,
> 
> Presumably, you mean stack segments there ;-)

Actually, I meant trail segments.

> > 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.)

OK, thanks. I wasn't sure, since non-trail stack segments are
unique to the LLDS backend.

Another question came to me, as I was writing the code to handle
pregen grades in the grade library, which is: should pregen be a grade
COMPONENT, or a complete grade? In other words: should pregen=yes
determine the value of ALL the other grade components? It has always
determined the value of tag location (low), number of tag bits (2),
boxed vs unboxed floats (boxed) and therefore spf=no. However,
it does not imply hlc, or .gc, or the absence of .ssdebug, or .par,
or any other feature. There is no intrinsic reason why it should,
but we use pregen for only one purpose, and for that purpose,
we also DO use pregen together with hlc and .gc and without
.ssdebug and .par etc. So in practice, I think it would be simpler
if pregen was a complete grade in itself, and not a grade component.

Any thought on this?

Something else that came up: I am reasonably sure that mprof
time profiling works only with the LLDS backend. However, I don't
know whether mprof time and memory profiling are supposed to work
when targeting high level C code. Does anyone know?

Zoltan.

Zoltan.