harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Fursov" <mike.fur...@gmail.com>
Subject Re: [drlvm][testing][jit] regular testing for JIT regressions on HUT
Date Fri, 29 Dec 2006 11:51:09 GMT
All,
HARMONY-1531 was frozed for some period of time because
1) I was busy with much higher priority tasks (wait for a set of new JIRA
issues from me after holidays:) )
2) Noone from JIT gurus was interested/had a time to help

My plans for the the next month is to add unrolling optimization to Jitrino
(I have already wrote some code) and to port magics support for EM64T and
IPF.
I'm going to use internal Jitrino testing framework to test loop unrolling
code. I'm not sure that my efforts will be enough to integrate it. So the
main answer for the question about H1531 readiness: it will be ready as soon
as other JIT developers start using it.

On 28 Dec 2006 20:23:41 +0600, Egor Pasko <egor.pasko@gmail.com> wrote:
>
> Well, actually, JIT IR-level tests are C-based too. Then, probably,
> c-unit is the best place?


The JIRA already contains JUnit integration for JIT internal tests. You can
add Cunit integration and put it into any test suite you want. I have no
preferences here.

I think, it makes sense to combine *all* types of tests in a single
> framefork with unified top-level running mechanisms as well as
> reporting mechanisms. When we have them all together we can cut them
> in pieces based on importance/time-to-run/catching-rate. Some pieces
> to run as pre-commit some in CC, some even more rare on snapshots, etc.
>
> > Now, that leaves smoke, kernel and regression.
> >
> > Smoke and kernel should be able to be combined.  Smoke just seems to
> > be tests where someone wanted to write their own testing framework.
>
> I like that
>
> > Regresssion -  I do understand where Tim is coming from in later
> > messages in this thread, but I don't actually mind slapping tests
> > that show reported bugs into a separate category called "regression",
> > because they probably are more complicated than unit tests or even
> > general functional tests, and a maybe poke at weird corner cases or
> > effects of multiple interacting systems.  It would be interesting to
> > see if our regression tests are finding things that unit tests should
> > have...
> >
> > geir
> >
>
> --
> Egor Pasko
>
>


-- 
Mikhail Fursov

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message