[zorg] r287418 - [AVR] Compile the X86 backend on the AVR builder
Roel Jordans via llvm-commits
llvm-commits at lists.llvm.org
Mon Nov 21 01:05:09 PST 2016
Another option is to set the AVR triple as default target during config
with something like:
|-DLLVM_DEFAULT_TARGET_TRIPLE="avr-unknown-unknown"|
That seems to work quite nicely for some of our own targets here,
provides you with some more test coverage, and avoids having to build
the x86 target.
Cheers,
Roel
On 19-11-16 04:04, Dylan McKay via llvm-commits wrote:
> I didn't realise that it was because they were targeting the host,
> that makes sense.
>
> It's impossible to self-host LLVM on AVR, so including the X86 backend
> is the easiest way forward anyway.
>
> Thanks for checking anyway :)
>
> On Sat, Nov 19, 2016 at 3:57 PM, Michael Kuperstein <mkuper at google.com
> <mailto:mkuper at google.com>> wrote:
>
> I looked at a couple, and they actually don't specify a triple -
> which means they expect to run with the host triple.
> I think expecting to be able to target the host is reasonable
> behavior, so this is probably fine.
>
> Sorry for the noise!
>
> On Fri, Nov 18, 2016 at 6:54 PM, Dylan McKay
> <dylanmckay34 at gmail.com <mailto:dylanmckay34 at gmail.com>> wrote:
>
> Yes, here's some of the tests that failed
>
> 1. FAIL: LLVM::2002-04-14-UnexpectedUnsignedType.ll
> <http://lab.llvm.org:8011/builders/llvm-avr-linux/builds/2/steps/test-llvm/logs/FAIL%3A%20LLVM%3A%3A2002-04-14-UnexpectedUnsignedType.ll>
> 2. FAIL: LLVM::2003-05-27-phifcmpd.ll
> <http://lab.llvm.org:8011/builders/llvm-avr-linux/builds/2/steps/test-llvm/logs/FAIL%3A%20LLVM%3A%3A2003-05-27-phifcmpd.ll>
> 3. FAIL: LLVM::2002-04-16-StackFrameSizeAlignment.ll
> <http://lab.llvm.org:8011/builders/llvm-avr-linux/builds/2/steps/test-llvm/logs/FAIL%3A%20LLVM%3A%3A2002-04-16-StackFrameSizeAlignment.ll>
> 4. FAIL: LLVM::2003-05-27-useboolinotherbb.ll
> <http://lab.llvm.org:8011/builders/llvm-avr-linux/builds/2/steps/test-llvm/logs/FAIL%3A%20LLVM%3A%3A2003-05-27-useboolinotherbb.ll>
> 5. FAIL: LLVM::2003-05-27-usefsubasbool.ll
> <http://lab.llvm.org:8011/builders/llvm-avr-linux/builds/2/steps/test-llvm/logs/FAIL%3A%20LLVM%3A%3A2003-05-27-usefsubasbool.ll>
> 6. FAIL: LLVM::2003-05-28-ManyArgs.ll
> <http://lab.llvm.org:8011/builders/llvm-avr-linux/builds/2/steps/test-llvm/logs/FAIL%3A%20LLVM%3A%3A2003-05-28-ManyArgs.ll>
> 7. FAIL: LLVM::2003-05-30-BadFoldGEP.ll
> <http://lab.llvm.org:8011/builders/llvm-avr-linux/builds/2/steps/test-llvm/logs/FAIL%3A%20LLVM%3A%3A2003-05-30-BadFoldGEP.ll>
> 8. FAIL: LLVM::2003-05-30-BadPreselectPhi.ll
> <http://lab.llvm.org:8011/builders/llvm-avr-linux/builds/2/steps/test-llvm/logs/FAIL%3A%20LLVM%3A%3A2003-05-30-BadPreselectPhi.ll>
> 9. FAIL: LLVM::2003-07-06-BadIntCmp.ll
> <http://lab.llvm.org:8011/builders/llvm-avr-linux/builds/2/steps/test-llvm/logs/FAIL%3A%20LLVM%3A%3A2003-07-06-BadIntCmp.ll>
> 10. FAIL: LLVM::2003-07-07-BadLongConst.ll
> <http://lab.llvm.org:8011/builders/llvm-avr-linux/builds/2/steps/test-llvm/logs/FAIL%3A%20LLVM%3A%3A2003-07-07-BadLongConst.ll>
> 11. FAIL: LLVM::2003-07-08-BadCastToBool.ll
> <http://lab.llvm.org:8011/builders/llvm-avr-linux/builds/2/steps/test-llvm/logs/FAIL%3A%20LLVM%3A%3A2003-07-08-BadCastToBool.ll>
> 12. FAIL: LLVM::2004-05-09-LiveVarPartialRegister.ll
> <http://lab.llvm.org:8011/builders/llvm-avr-linux/builds/2/steps/test-llvm/logs/FAIL%3A%20LLVM%3A%3A2004-05-09-LiveVarPartialRegister.ll>
> 13. FAIL: LLVM::2003-07-29-BadConstSbyte.ll
> <http://lab.llvm.org:8011/builders/llvm-avr-linux/builds/2/steps/test-llvm/logs/FAIL%3A%20LLVM%3A%3A2003-07-29-BadConstSbyte.ll>
> 14. FAIL: LLVM::2005-04-09-GlobalInPHI.ll
> <http://lab.llvm.org:8011/builders/llvm-avr-linux/builds/2/steps/test-llvm/logs/FAIL%3A%20LLVM%3A%3A2005-04-09-GlobalInPHI.ll>
> 15. FAIL: LLVM::2005-01-18-SetUO-InfLoop.ll
> <http://lab.llvm.org:8011/builders/llvm-avr-linux/builds/2/steps/test-llvm/logs/FAIL%3A%20LLVM%3A%3A2005-01-18-SetUO-InfLoop.ll>
> 16. FAIL: LLVM::2005-10-21-longlonggtu.ll
> <http://lab.llvm.org:8011/builders/llvm-avr-linux/builds/2/steps/test-llvm/logs/FAIL%3A%20LLVM%3A%3A2005-10-21-longlonggtu.ll>
> 17. FAIL: LLVM::2005-10-18-ZeroSizeStackObject.ll
> <http://lab.llvm.org:8011/builders/llvm-avr-linux/builds/2/steps/test-llvm/logs/FAIL%3A%20LLVM%3A%3A2005-10-18-ZeroSizeStackObject.ll>
> 18. FAIL: LLVM::2005-12-01-Crash.ll
> <http://lab.llvm.org:8011/builders/llvm-avr-linux/builds/2/steps/test-llvm/logs/FAIL%3A%20LLVM%3A%3A2005-12-01-Crash.ll>
> 19. FAIL: LLVM::2005-12-12-ExpandSextInreg.ll
> <http://lab.llvm.org:8011/builders/llvm-avr-linux/builds/2/steps/test-llvm/logs/FAIL%3A%20LLVM%3A%3A2005-12-12-ExpandSextInreg.ll>
>
>
> http://lab.llvm.org:8011/builders/llvm-avr-linux/builds/2
> <http://lab.llvm.org:8011/builders/llvm-avr-linux/builds/2>
>
> The errors tend to look like
>
> error: unable to get target for 'x86_64-unknown-linux-gnu'
>
> And at least some of the tests are in the
> llvm/test/CodeGen/Generic directory
>
> On Sat, Nov 19, 2016 at 3:47 PM, Michael Kuperstein
> <mkuper at google.com <mailto:mkuper at google.com>> wrote:
>
> This doesn't look right. I may be wrong, but AFAIK, we
> shouldn't have generic tests that depend on a specific
> backend.
>
> Are those tests that have an X86 triple that live in a
> non-X86 specific directory?
>
> On Fri, Nov 18, 2016 at 5:39 PM, Dylan McKay via
> llvm-commits <llvm-commits at lists.llvm.org
> <mailto:llvm-commits at lists.llvm.org>> wrote:
>
> Author: dylanmckay
> Date: Fri Nov 18 19:39:07 2016
> New Revision: 287418
>
> URL:
> http://llvm.org/viewvc/llvm-project?rev=287418&view=rev
> <http://llvm.org/viewvc/llvm-project?rev=287418&view=rev>
> Log:
> [AVR] Compile the X86 backend on the AVR builder
>
> There were a bunch of generic CodeGen tests which
> required that the X86
> backend is included.
>
> Modified:
> zorg/trunk/buildbot/osuosl/master/config/builders.py
>
> Modified:
> zorg/trunk/buildbot/osuosl/master/config/builders.py
> URL:
> http://llvm.org/viewvc/llvm-project/zorg/trunk/buildbot/osuosl/master/config/builders.py?rev=287418&r1=287417&r2=287418&view=diff
> <http://llvm.org/viewvc/llvm-project/zorg/trunk/buildbot/osuosl/master/config/builders.py?rev=287418&r1=287417&r2=287418&view=diff>
> ==============================================================================
> ---
> zorg/trunk/buildbot/osuosl/master/config/builders.py
> (original)
> +++
> zorg/trunk/buildbot/osuosl/master/config/builders.py
> Fri Nov 18 19:39:07 2016
> @@ -81,7 +81,8 @@ def _get_llvm_builders():
> extra_cmake_args=[
> "-G", "Unix Makefiles",
> "-DCMAKE_BUILD_TYPE:STRING=Release",
> - "-DLLVM_TARGETS_TO_BUILD:STRING=AVR",
> + # We need to compile the X86 backend due to a few
> generic CodeGen tests.
> + "-DLLVM_TARGETS_TO_BUILD:STRING=AVR;X86",
> "-DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD:STRING=AVR",
> ])}
> ]
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> <mailto:llvm-commits at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
> <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits>
>
>
>
>
>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20161121/a6d5ea36/attachment.html>
More information about the llvm-commits
mailing list