spop at codeaurora.org
2011-Nov-04 22:11 UTC
[LLVMdev] JIT should query host info at runtime - Re: buildbot failure in LLVM on llvm-gcc-build-x86_64-darwin10-x-mingw32-x-armeabi
Hi Daniel,> Sebastian, this looks like it is most likely some kind of fallout from > your changes.Thanks for letting me know about these failing testcases. In the logs of the buildbot: http://lab.llvm.org:8011/builders/llvm-gcc-build-x86_64-darwin10-x-mingw32-x-armeabi/builds/273/steps/run.build.step.configure_llvm_1/logs/stdio I see that the bot is configuring llvm with: --build=x86_64-apple-darwin10 --host=x86_64-apple-darwin10 --target=i686-pc-mingw32 Before my patches, specifying --target had no effect as it was the --host value that was taken. So by default we used to compile code for the host that is "x86_64-apple-darwin10". After my patches, the value set with --target is used. So now, by default this build bot will generate code for "i686-pc-mingw32". I think that these fails are due to the fact that the testcases are not working when the target is specified to be different than host: in the following list of failing testcases I see the JIT cases failing: Failing Tests (26): LLVM :: ExecutionEngine/2002-12-16-ArgTest.ll LLVM :: ExecutionEngine/2003-01-04-ArgumentBug.ll LLVM :: ExecutionEngine/2003-01-04-LoopTest.ll LLVM :: ExecutionEngine/2003-01-15-AlignmentTest.ll LLVM :: ExecutionEngine/2003-05-06-LivenessClobber.ll LLVM :: ExecutionEngine/2003-05-07-ArgumentTest.ll LLVM :: ExecutionEngine/2003-06-04-bzip2-bug.ll LLVM :: ExecutionEngine/2003-08-15-AllocaAssertion.ll LLVM :: ExecutionEngine/2003-08-21-EnvironmentTest.ll LLVM :: ExecutionEngine/2003-08-23-RegisterAllocatePhysReg.ll LLVM :: ExecutionEngine/2003-10-18-PHINode-ConstantExpr-CondCode-Failure.ll LLVM :: ExecutionEngine/2005-12-02-TailCallBug.ll LLVM :: ExecutionEngine/hello.ll LLVM :: ExecutionEngine/hello2.ll LLVM :: ExecutionEngine/stubs.ll LLVM :: ExecutionEngine/test-call.ll LLVM :: ExecutionEngine/test-fp.ll LLVM :: ExecutionEngine/test-loadstore.ll LLVM-Unit :: ExecutionEngine/JIT/Debug+Asserts/JITTests/JIT.GlobalInFunction LLVM-Unit :: ExecutionEngine/JIT/Debug+Asserts/JITTests/JITTest.AvailableExternallyGlobalIsntEmitted LLVM-Unit :: ExecutionEngine/JIT/Debug+Asserts/JITTests/JITTest.EscapedLazyStubStillCallable LLVM-Unit :: ExecutionEngine/JIT/Debug+Asserts/JITTests/JITTest.FarCallToKnownFunction LLVM-Unit :: ExecutionEngine/JIT/Debug+Asserts/JITTests/JITTest.FunctionPointersOutliveTheirCreator LLVM-Unit :: ExecutionEngine/JIT/Debug+Asserts/JITTests/LazyLoadedJITTest.EagerCompiledRecursionThroughGhost LLVM-Unit :: ExecutionEngine/JIT/Debug+Asserts/JITTests/MultiJitTest.EagerMode LLVM-Unit :: ExecutionEngine/JIT/Debug+Asserts/JITTests/MultiJitTest.LazyMode I think that for JIT, the compiler should figure out what the host is with a *runtime* check (i.e., the JIT should not use the info from the configure flag --host.) Thanks, Sebastian> > - Daniel > > On Nov 1, 2011, at 5:26 PM, llvm.buildmaster at lab.llvm.org wrote: > >> The Buildbot has detected a new failure on builder >> llvm-gcc-build-x86_64-darwin10-x-mingw32-x-armeabi while building LLVM. >> Full details are available at: >> http://lab.llvm.org:8011/builders/llvm-gcc-build-x86_64-darwin10-x-mingw32-x-armeabi/builds/273 >> >> Buildbot URL: http://lab.llvm.org:8011/ >> >> Buildslave for this Build: kistanova1 >> >> Build Reason: scheduler >> Build Source Stamp: 143501 >> Blamelist: ddunbar,efriedma,spop >> >> BUILD FAILED: failed run.build.step.test_llvm_1 >> >> sincerely, >> -The Buildbot >> >> >> > >
Eric Christopher
2011-Nov-04 22:15 UTC
[LLVMdev] JIT should query host info at runtime - Re: buildbot failure in LLVM on llvm-gcc-build-x86_64-darwin10-x-mingw32-x-armeabi
On Nov 4, 2011, at 3:11 PM, spop at codeaurora.org wrote:> I think that for JIT, the compiler should figure out what the host > is with a *runtime* check (i.e., the JIT should not use the info from > the configure flag --host.)That seems reasonable. Would you update this please? Thanks! -eric -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111104/2d3d82b5/attachment.html>
Eli Friedman
2011-Nov-04 22:16 UTC
[LLVMdev] JIT should query host info at runtime - Re: buildbot failure in LLVM on llvm-gcc-build-x86_64-darwin10-x-mingw32-x-armeabi
On Fri, Nov 4, 2011 at 3:11 PM, <spop at codeaurora.org> wrote:> Hi Daniel, > >> Sebastian, this looks like it is most likely some kind of fallout from >> your changes. > > Thanks for letting me know about these failing testcases. > > In the logs of the buildbot: > http://lab.llvm.org:8011/builders/llvm-gcc-build-x86_64-darwin10-x-mingw32-x-armeabi/builds/273/steps/run.build.step.configure_llvm_1/logs/stdio > I see that the bot is configuring llvm with: > --build=x86_64-apple-darwin10 --host=x86_64-apple-darwin10 > --target=i686-pc-mingw32 > > Before my patches, specifying --target had no effect as it was the > --host value that was taken. So by default we used to compile code > for the host that is "x86_64-apple-darwin10". > > After my patches, the value set with --target is used. So now, by > default this build bot will generate code for "i686-pc-mingw32". I > think that these fails are due to the fact that the testcases are not > working when the target is specified to be different than host: in the > following list of failing testcases I see the JIT cases failing: > > Failing Tests (26): > LLVM :: ExecutionEngine/2002-12-16-ArgTest.ll > LLVM :: ExecutionEngine/2003-01-04-ArgumentBug.ll > LLVM :: ExecutionEngine/2003-01-04-LoopTest.ll > LLVM :: ExecutionEngine/2003-01-15-AlignmentTest.ll > LLVM :: ExecutionEngine/2003-05-06-LivenessClobber.ll > LLVM :: ExecutionEngine/2003-05-07-ArgumentTest.ll > LLVM :: ExecutionEngine/2003-06-04-bzip2-bug.ll > LLVM :: ExecutionEngine/2003-08-15-AllocaAssertion.ll > LLVM :: ExecutionEngine/2003-08-21-EnvironmentTest.ll > LLVM :: ExecutionEngine/2003-08-23-RegisterAllocatePhysReg.ll > LLVM :: > ExecutionEngine/2003-10-18-PHINode-ConstantExpr-CondCode-Failure.ll > LLVM :: ExecutionEngine/2005-12-02-TailCallBug.ll > LLVM :: ExecutionEngine/hello.ll > LLVM :: ExecutionEngine/hello2.ll > LLVM :: ExecutionEngine/stubs.ll > LLVM :: ExecutionEngine/test-call.ll > LLVM :: ExecutionEngine/test-fp.ll > LLVM :: ExecutionEngine/test-loadstore.ll > LLVM-Unit :: > ExecutionEngine/JIT/Debug+Asserts/JITTests/JIT.GlobalInFunction > LLVM-Unit :: > ExecutionEngine/JIT/Debug+Asserts/JITTests/JITTest.AvailableExternallyGlobalIsntEmitted > LLVM-Unit :: > ExecutionEngine/JIT/Debug+Asserts/JITTests/JITTest.EscapedLazyStubStillCallable > LLVM-Unit :: > ExecutionEngine/JIT/Debug+Asserts/JITTests/JITTest.FarCallToKnownFunction > LLVM-Unit :: > ExecutionEngine/JIT/Debug+Asserts/JITTests/JITTest.FunctionPointersOutliveTheirCreator > LLVM-Unit :: > ExecutionEngine/JIT/Debug+Asserts/JITTests/LazyLoadedJITTest.EagerCompiledRecursionThroughGhost > LLVM-Unit :: > ExecutionEngine/JIT/Debug+Asserts/JITTests/MultiJitTest.EagerMode > LLVM-Unit :: > ExecutionEngine/JIT/Debug+Asserts/JITTests/MultiJitTest.LazyMode > > I think that for JIT, the compiler should figure out what the host > is with a *runtime* check (i.e., the JIT should not use the info from > the configure flag --host.)Err, what? We can and should compute the host with a compile-time check; how would you possibly run lli on a platform that isn't the same as --host? -Eli
spop at codeaurora.org
2011-Nov-04 22:22 UTC
[LLVMdev] JIT should query host info at runtime - Re: buildbot failure in LLVM on llvm-gcc-build-x86_64-darwin10-x-mingw32-x-armeabi
> > On Nov 4, 2011, at 3:11 PM, spop at codeaurora.org wrote: > >> I think that for JIT, the compiler should figure out what the host >> is with a *runtime* check (i.e., the JIT should not use the info from >> the configure flag --host.) > > That seems reasonable. Would you update this please? >Yes, I would be happy to find the best fix for this. Thinking a bit more, I don't see a good reason to not use the value set by configure --host. At configure time, we know the kind machine on which the compiler will run, so that's the machine we should target when JITting. Opinions? Thanks, Sebastian
Eric Christopher
2011-Nov-04 22:22 UTC
[LLVMdev] JIT should query host info at runtime - Re: buildbot failure in LLVM on llvm-gcc-build-x86_64-darwin10-x-mingw32-x-armeabi
On Nov 4, 2011, at 3:16 PM, Eli Friedman wrote:> Err, what? We can and should compute the host with a compile-time > check; how would you possibly run lli on a platform that isn't the > same as --host?lli in interp mode sure, but generating native code? -eric -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111104/fff7bf81/attachment.html>
Sebastian Pop
2011-Nov-04 22:28 UTC
[LLVMdev] JIT should query host info at runtime - Re: buildbot failure in LLVM on llvm-gcc-build-x86_64-darwin10-x-mingw32-x-armeabi
On Fri, Nov 4, 2011 at 5:16 PM, Eli Friedman <eli.friedman at gmail.com> wrote:>> I think that for JIT, the compiler should figure out what the host >> is with a *runtime* check (i.e., the JIT should not use the info from >> the configure flag --host.) > > Err, what? We can and should compute the host with a compile-time > check; how would you possibly run lli on a platform that isn't the > same as --host?You are right, when we use the compiler as a JIT, runtime = compile time so we would need to figure out the host at that time. Sebastian -- Qualcomm Innovation Center, Inc is a member of Code Aurora Forum
Daniel Dunbar
2011-Nov-04 22:28 UTC
[LLVMdev] JIT should query host info at runtime - Re: buildbot failure in LLVM on llvm-gcc-build-x86_64-darwin10-x-mingw32-x-armeabi
I actually tend to agree with spop, it's cleaner to compute things at runtime than at compile time. One particular reason is wanting to pick the best target CPU for the current arch (which may not be what was compiled for). The current JIT target selection logic is really gross, I do believe that it tried to do this, but it probably needs some spring cleaning. Sebastian, can you try and take a look? We don't want to regress on these tests, at least. - Daniel On Fri, Nov 4, 2011 at 3:16 PM, Eli Friedman <eli.friedman at gmail.com> wrote:> On Fri, Nov 4, 2011 at 3:11 PM, <spop at codeaurora.org> wrote: >> Hi Daniel, >> >>> Sebastian, this looks like it is most likely some kind of fallout from >>> your changes. >> >> Thanks for letting me know about these failing testcases. >> >> In the logs of the buildbot: >> http://lab.llvm.org:8011/builders/llvm-gcc-build-x86_64-darwin10-x-mingw32-x-armeabi/builds/273/steps/run.build.step.configure_llvm_1/logs/stdio >> I see that the bot is configuring llvm with: >> --build=x86_64-apple-darwin10 --host=x86_64-apple-darwin10 >> --target=i686-pc-mingw32 >> >> Before my patches, specifying --target had no effect as it was the >> --host value that was taken. So by default we used to compile code >> for the host that is "x86_64-apple-darwin10". >> >> After my patches, the value set with --target is used. So now, by >> default this build bot will generate code for "i686-pc-mingw32". I >> think that these fails are due to the fact that the testcases are not >> working when the target is specified to be different than host: in the >> following list of failing testcases I see the JIT cases failing: >> >> Failing Tests (26): >> LLVM :: ExecutionEngine/2002-12-16-ArgTest.ll >> LLVM :: ExecutionEngine/2003-01-04-ArgumentBug.ll >> LLVM :: ExecutionEngine/2003-01-04-LoopTest.ll >> LLVM :: ExecutionEngine/2003-01-15-AlignmentTest.ll >> LLVM :: ExecutionEngine/2003-05-06-LivenessClobber.ll >> LLVM :: ExecutionEngine/2003-05-07-ArgumentTest.ll >> LLVM :: ExecutionEngine/2003-06-04-bzip2-bug.ll >> LLVM :: ExecutionEngine/2003-08-15-AllocaAssertion.ll >> LLVM :: ExecutionEngine/2003-08-21-EnvironmentTest.ll >> LLVM :: ExecutionEngine/2003-08-23-RegisterAllocatePhysReg.ll >> LLVM :: >> ExecutionEngine/2003-10-18-PHINode-ConstantExpr-CondCode-Failure.ll >> LLVM :: ExecutionEngine/2005-12-02-TailCallBug.ll >> LLVM :: ExecutionEngine/hello.ll >> LLVM :: ExecutionEngine/hello2.ll >> LLVM :: ExecutionEngine/stubs.ll >> LLVM :: ExecutionEngine/test-call.ll >> LLVM :: ExecutionEngine/test-fp.ll >> LLVM :: ExecutionEngine/test-loadstore.ll >> LLVM-Unit :: >> ExecutionEngine/JIT/Debug+Asserts/JITTests/JIT.GlobalInFunction >> LLVM-Unit :: >> ExecutionEngine/JIT/Debug+Asserts/JITTests/JITTest.AvailableExternallyGlobalIsntEmitted >> LLVM-Unit :: >> ExecutionEngine/JIT/Debug+Asserts/JITTests/JITTest.EscapedLazyStubStillCallable >> LLVM-Unit :: >> ExecutionEngine/JIT/Debug+Asserts/JITTests/JITTest.FarCallToKnownFunction >> LLVM-Unit :: >> ExecutionEngine/JIT/Debug+Asserts/JITTests/JITTest.FunctionPointersOutliveTheirCreator >> LLVM-Unit :: >> ExecutionEngine/JIT/Debug+Asserts/JITTests/LazyLoadedJITTest.EagerCompiledRecursionThroughGhost >> LLVM-Unit :: >> ExecutionEngine/JIT/Debug+Asserts/JITTests/MultiJitTest.EagerMode >> LLVM-Unit :: >> ExecutionEngine/JIT/Debug+Asserts/JITTests/MultiJitTest.LazyMode >> >> I think that for JIT, the compiler should figure out what the host >> is with a *runtime* check (i.e., the JIT should not use the info from >> the configure flag --host.) > > Err, what? We can and should compute the host with a compile-time > check; how would you possibly run lli on a platform that isn't the > same as --host? > > -Eli > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >
Sebastian Pop
2011-Dec-27 19:36 UTC
[LLVMdev] JIT should query host info at runtime - Re: buildbot failure in LLVM on llvm-gcc-build-x86_64-darwin10-x-mingw32-x-armeabi
Hi, On Fri, Nov 4, 2011 at 5:11 PM, <spop at codeaurora.org> wrote:> Hi Daniel, > >> Sebastian, this looks like it is most likely some kind of fallout from >> your changes. > > Thanks for letting me know about these failing testcases. > > In the logs of the buildbot: > http://lab.llvm.org:8011/builders/llvm-gcc-build-x86_64-darwin10-x-mingw32-x-armeabi/builds/273/steps/run.build.step.configure_llvm_1/logs/stdio > I see that the bot is configuring llvm with: > --build=x86_64-apple-darwin10 --host=x86_64-apple-darwin10 > --target=i686-pc-mingw32 > > Before my patches, specifying --target had no effect as it was the > --host value that was taken. So by default we used to compile code > for the host that is "x86_64-apple-darwin10". > > After my patches, the value set with --target is used. So now, by > default this build bot will generate code for "i686-pc-mingw32". I > think that these fails are due to the fact that the testcases are not > working when the target is specified to be different than host: in the > following list of failing testcases I see the JIT cases failing: > > Failing Tests (26): > LLVM :: ExecutionEngine/2002-12-16-ArgTest.ll > LLVM :: ExecutionEngine/2003-01-04-ArgumentBug.ll > LLVM :: ExecutionEngine/2003-01-04-LoopTest.ll > LLVM :: ExecutionEngine/2003-01-15-AlignmentTest.ll > LLVM :: ExecutionEngine/2003-05-06-LivenessClobber.ll > LLVM :: ExecutionEngine/2003-05-07-ArgumentTest.ll > LLVM :: ExecutionEngine/2003-06-04-bzip2-bug.ll > LLVM :: ExecutionEngine/2003-08-15-AllocaAssertion.ll > LLVM :: ExecutionEngine/2003-08-21-EnvironmentTest.ll > LLVM :: ExecutionEngine/2003-08-23-RegisterAllocatePhysReg.ll > LLVM :: > ExecutionEngine/2003-10-18-PHINode-ConstantExpr-CondCode-Failure.ll > LLVM :: ExecutionEngine/2005-12-02-TailCallBug.ll > LLVM :: ExecutionEngine/hello.ll > LLVM :: ExecutionEngine/hello2.ll > LLVM :: ExecutionEngine/stubs.ll > LLVM :: ExecutionEngine/test-call.ll > LLVM :: ExecutionEngine/test-fp.ll > LLVM :: ExecutionEngine/test-loadstore.ll > LLVM-Unit :: > ExecutionEngine/JIT/Debug+Asserts/JITTests/JIT.GlobalInFunction > LLVM-Unit :: > ExecutionEngine/JIT/Debug+Asserts/JITTests/JITTest.AvailableExternallyGlobalIsntEmitted > LLVM-Unit :: > ExecutionEngine/JIT/Debug+Asserts/JITTests/JITTest.EscapedLazyStubStillCallable > LLVM-Unit :: > ExecutionEngine/JIT/Debug+Asserts/JITTests/JITTest.FarCallToKnownFunction > LLVM-Unit :: > ExecutionEngine/JIT/Debug+Asserts/JITTests/JITTest.FunctionPointersOutliveTheirCreator > LLVM-Unit :: > ExecutionEngine/JIT/Debug+Asserts/JITTests/LazyLoadedJITTest.EagerCompiledRecursionThroughGhost > LLVM-Unit :: > ExecutionEngine/JIT/Debug+Asserts/JITTests/MultiJitTest.EagerMode > LLVM-Unit :: > ExecutionEngine/JIT/Debug+Asserts/JITTests/MultiJitTest.LazyMode > > I think that for JIT, the compiler should figure out what the host > is with a *runtime* check (i.e., the JIT should not use the info from > the configure flag --host.) >Until we fix this with the runtime check, here is the fix that introduces back the function getHostTriple that returns the configure --host information and uses it from the JIT. Ok to commit this patch as an interim fix? Thanks, Sebastian -- Qualcomm Innovation Center, Inc is a member of Code Aurora Forum -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-use-getHostTriple-instead-of-getDefaultTargetTriple-.patch Type: text/x-diff Size: 9047 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111227/5ae6f46f/attachment.patch>
Possibly Parallel Threads
- [LLVMdev] JIT should query host info at runtime - Re: buildbot failure in LLVM on llvm-gcc-build-x86_64-darwin10-x-mingw32-x-armeabi
- [LLVMdev] JIT should query host info at runtime - Re: buildbot failure in LLVM on llvm-gcc-build-x86_64-darwin10-x-mingw32-x-armeabi
- [LLVMdev] sys::getHostTriple failed to recognize ARM correctly
- [LLVMdev] LLVM 3.0rc4 / 2.9: failing MultiJitTest.JitPool on Windows 7
- [LLVMdev] LLVM 3.0rc4 / 2.9: failing MultiJitTest.JitPool on Windows 7