[LLVMdev] JIT should query host info at runtime - Re: buildbot failure in LLVM on llvm-gcc-build-x86_64-darwin10-x-mingw32-x-armeabi

Eli Friedman eli.friedman at gmail.com
Fri Nov 4 15:16:37 PDT 2011


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




More information about the llvm-dev mailing list