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

[Reed Kotler]

Hi Daniel,

This follow up patch by Doug seems to be what you were asking for.

Can we commit this?

TIA.

Reed

On 07/25/2013 04:23 PM, Doug Gilmore 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-1AXoQHu6uovQT0dZR+AlfA at public.gmane.org> 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:
>>          > > ...
>>
>>
>>
>>
>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits-Tmj1lob9twqVc3sceRu5cw at public.gmane.org
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Makefile.programs.patch
Type: text/x-patch
Size: 603 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130729/d8e7b891/attachment.bin>