[PATCH] D43119: [zorg] Add AArch32 global-isel bots

Maxim Kuvyrkov via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Feb 13 08:18:31 PST 2018


maxim-kuvyrkov added inline comments.


================
Comment at: buildbot/osuosl/master/config/builders.py:324
+                      runTestSuite=True,
+                      testsuite_flags=['--cppflags', '-O0 -mllvm -global-isel -mllvm -global-isel-abort=0',
+                                       '--threads=64', '--build-threads=64'],
----------------
rengolin wrote:
> rovka wrote:
> > maxim-kuvyrkov wrote:
> > > rovka wrote:
> > > > Well, technically my patch was only for the ARMv7 part. I'm not sure how this one is supposed to work. What makes this AArch32? If we run on an armv8 machine, won't it by default use AArch64?
> > > Docker containers are started on ARMv8 machine under "linux32" personality and with armhf ubuntu rootfs.  This makes LLVM detect bot as armv8l-linux-gnueabihf .
> > Ah, ok. I'd like it better if we set the triple on the command line, since that would make things more explicit. Alternatively, it might be a good idea to build only the ARM target, and not AArch64, to make sure things blow up if this ends up on a misconfigured container in the future.
> I agree with @rovka, you shouldn't rely on the host to tell you what to run. We also want to test armv7 and armv8, so for now, setting the triple to armv8 should be fine, but we shouldn't disable the armv7 bot later in the future, as the code-gen path are different.
> 
> Now I remember why I chose to also force the CPU: because A15 stresses almost all relevant instructions form the ARMv7 set. If you don't choose anything you can end up picking A8 which will be the bare minimum.
> 
> In the ARMv8 case, you'll probably have A53, which will test more instructions, but will also stop testing ARMv7 specific paths. So, if we move to 32-bit emulation for ARMv7, we should have *both* ARMv7+A15 and ARMv8+A53/7.
> 
> Making the flags explicit also help reproducing builds and test, both for bisecting and investigating as well as re-building the container and getting a different behaviour (but still the same builds).
Agree.  I'm going to experiment with setting clang/LLVM default flags at cmake stage; if that doesn't work, we'll just pass triple via testsuite flags.


Repository:
  rL LLVM

https://reviews.llvm.org/D43119





More information about the llvm-commits mailing list