[LLVMdev] [llvm-commits] [llvm] r160610 - /llvm/trunk/lib/ExecutionEngine/TargetSelect.cpp

NAKAMURA Takumi geek4civic at gmail.com
Thu Sep 13 03:34:57 PDT 2012

2012/9/13 Kaylor, Andrew <andrew.kaylor at intel.com>:
> I'm a bit confused as to what is supposed to happen in the cross building scenarios.  For instance, if host=x86_64-linux and target=i686-mingw32, what should the MCJIT tests do?  Should they be suppressed because the architectures don't match?  If so, what about the case where host=x86_64-linux and target=x86_64-mingw32?

Basically, I don't think local JIT could execute other environments.
Both {i686|x86_64}-mingw32 are incompatible to Linux, at least.

It should be suppressed unless the target could run as RemoteTarget.

BTW, do you think -target i686-linux should run under x86_64 binary?
(I wish so, but it would involve some issues...)

> I'm modifying the MCJIT tests so that they will provide an explicit target triple on the run line.  In the case where the host OS is Windows, I'm appending "-elf" to the target triple.  I think that should be sufficient to make things work in the cases where the host triple and the target triple are compatible, and then I can suppress the cases where host and target aren't compatible in the lit.local.cfg file.
> Does that sound right?

Do you mean; "-mtriple=%{targettriple_provided_by_lit}-elf" ?
I think MCJIT may reinterpret the triple to be accepted by elf.

> My concern is that I don't quite know how to predict what will happen on some of the buildbots aside from checking something in and seeing what happens.  Hopefully any obvious problems will be caught in code review.

I can investigate failures if they happened in my builders. All of my
builders are in my room :)

> Aside from the testing, it seems to me that TargetSelect should always use the Module target triple, and if it isn't compatible with the host environment then it will just fail.

It should be better that Target may be overridden. It was the reason
why I tweaked TargetSelect().


More information about the llvm-dev mailing list