[PATCH] D42040: [PATCH 5/6] [zorg] Add linaro-armv8-01-arm-* slaves

[Maxim Kuvyrkov via Phabricator via llvm-commits]

maxim-kuvyrkov added inline comments.


================
Comment at: buildbot/osuosl/master/config/builders.py:226
         {'name' : "clang-native-arm-lnt",
-         'slavenames':["linaro-tk1-03"],
+         'slavenames':["linaro-tk1-03", "linaro-armv8-01-arm-lnt"],
          'builddir':"clang-native-arm-lnt",
----------------
rovka wrote:
> If we're not going to connect both of these at the same time, then why don't we remove the TK1 from the slave list and only commit this when the armv8 slaves are ready to take over? Then we can safely disconnect the TK1s any time afterwards. 
We are not going to connect these at the same time *for the same builder*.  I plan to de-commission TK1s one-by-one, one builder at a time.  I.e.,
1. connect linaro-armv8-01-arm-lnt to silent master, linaro-tk1-03 is connected to main master;
2. confirm that linaro-armv8-01-arm-lnt works OK on silent master;
3. connect linaro-armv8-01-arm-lnt to main master, connect linaro-tk1-03 to silent master;
4. confirm that linaro-armv8-01-arm-lnt works OK on main master;
5. disconnect linaro-tk1-03 from silent master and repurpose hardware for something else.



================
Comment at: buildbot/osuosl/master/config/builders.py:235
                       runTestSuite=True,
                       testsuite_flags=['--cppflags', '-mcpu=cortex-a15 -marm',
                                        '--threads=4', '--build-threads=4'],
----------------
rovka wrote:
> Should this still be cortex-a15, or should we be using a different combination of flags?
I think it should remain cortex-a15 for now.  The question is which codegen path should be explicitly exercised?  Since cortex-a15 is a popular core, imo, we should leave this as is.

Once migration is finished and we can increase number of configurations that we can test, we should add builders for other popular cores -- as long as they are compatible with hardware underneath.


Repository:
  rL LLVM

https://reviews.llvm.org/D42040