[LNT][Patch] Bug 16261 - lnt incorrectly builds timeit-target when one is using a simulator

Daniel Dunbar daniel at zuster.org
Mon Jul 29 09:56:37 PDT 2013


Hi Doug,

Thanks for the revision, yes the patch looks fine to me feel free to have
Reed commit.

 - Daniel


On Thu, Jul 25, 2013 at 4:23 PM, Doug Gilmore <Doug.Gilmore at imgtec.com>wrote:

> On Thu, 2013-07-25 at 14:47 -0700, Daniel Dunbar wrote:
> > Ok, this seems like a pretty custom situation, I'd rather that have
> > minimal impact on the LNT code paths. It doesn't generally make any
> > sense to compile "timeit-target" for the host.
> >
> >
> > Could you instead implement this as a patch to instead cause "timeit"
> > to be used instead of "timeit-target". This should be as simple as
> > adding a new Makefile variable that will be used in Makefile.programs
> > to cause RUNSAFELY to use timeit instead of timeit-target. Then you
> > can use LNT's existing --make-param option to pass that in.
> >
> >
> >  - Daniel
> That's great -- my patch needed cleanup anyway and your approach
> finesses that issue.
>
> Patch attached.
>
> Thanks!
>
> Doug
> >
> >
> > On Wed, Jul 24, 2013 at 11:37 AM, Doug Gilmore
> > <Doug.Gilmore at imgtec.com> wrote:
> >         On Tue, 2013-07-23 at 17:17 -0700, an Reed Kotler wrote:
> >         >
> >         > In this case we are not using lnt under Qemu user mode for
> >         benchmarking;
> >         > just as a way to run test-suite to test whether the code is
> >         correct.
> >         >
> >         > Qemu user mode emulates target instructions, but when it
> >         gets a Unix
> >         > Kernel trap, it uses the host to emulate those.
> >         >
> >         > For example, file I/O.
> >         >
> >         > It is possible to run target timeit under qemu and let it
> >         launch the app
> >         > or a wrapper.
> >         > (But it is more limited as to what can be done here under
> >         qemu vs under
> >         > the host OS directly).
> >         >
> >         > For time functions, it is also going to use the host to
> >         emulate those.
> >         >
> >         > So whether timeit is running under qemu or directly on the
> >         host, the
> >         > answers regarding time will be the same.
> >         >
> >         > But running timeit under qemu will be much slower as far as
> >         elapsed time
> >         > than running it on the host directly.
> >         >
> >         > We would also need to add some new mechanism to Lnt or the
> >         makefiles to
> >         > also wrap timeit.
> >
> >         Good point Reed -- thanks!
> >         >
> >         > Reed
> >         >
> >         >
> >         > On 07/23/2013 02:19 PM, Daniel Dunbar wrote:
> >         > > Wouldn't it be a more accurate simulation to run
> >         timeit-target under
> >         > > the emulator as well? Or is that too much to ask?
> >         > >
> >         > >  - Daniel
> >
> >         Hi Daniel,
> >
> >         I agree with Reed's discussion of the issues.  We are mainly
> >         concerned with
> >         the correctness when running under QEMU, though the the timing
> >         data
> >         might be useful at a very course grain level.
> >
> >         Doug
> >         > >
> >         > >
> >         > > On Mon, Jul 22, 2013 at 6:47 PM, Reed Kotler <rkotler at
> >         mips.com
> >         > > <mailto:rkotler at mips.com>> wrote:
> >         > > ...
> >
> >
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130729/3ba6810e/attachment.html>


More information about the llvm-commits mailing list