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

Project Infrastructure LLVM Dev List Archives
#1

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

#2

That seems reasonable. Would you update this please?

Thanks!

-eric

#3

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

#4

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

#5

lli in interp mode sure, but generating native code?

-eric

#6

Yes. :slight_smile:

This is what I was trying to say (and Eli came by to ask what I meant too :).

-eric

#7

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

#8

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

#9

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).

Right. If we query the host info at JIT compile time, we would get the
best info to select the native mode. It is impossible to get to this precise
info about the host at configure time.

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.

Yes, I will also take a look at this.

Sebastian

#10

Hi,

0001-use-getHostTriple-instead-of-getDefaultTargetTriple-.patch (8.83 KB)