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

Daniel Dunbar daniel at zuster.org
Fri Nov 4 15:28:41 PDT 2011


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
>




More information about the llvm-dev mailing list