This is an archive of the discontinued LLVM Phabricator instance.

[buildbot] Add slave to test libomp for ppc64le targets.
ClosedPublic

Authored by sfantao on Jan 9 2017, 3:12 PM.

Details

Summary

This patch adds a slave to test libomp for powerpc64 little endian. This configuration is known to work but didn't have a bot to actually do the testing.

The configuration uses the existing builder infrastructure already in place for x86. The intent is to extend the testing to cover OpenMP offloading (libomptarget) when it is ready in the OpenMP project. The slave has an NVIDIA K40 GPU ready for that purpose.

Diff Detail

Event Timeline

sfantao updated this revision to Diff 83715.Jan 9 2017, 3:12 PM
sfantao retitled this revision from to [buildbot] Add slave to test libomp for ppc64le targets..
sfantao updated this object.
sfantao added a subscriber: caomhin.
gkistanova edited edge metadata.Jan 9 2017, 4:32 PM

LGTM.

Thanks

Galina

gkistanova accepted this revision.Jan 9 2017, 4:42 PM
gkistanova edited edge metadata.
This revision is now accepted and ready to land.Jan 9 2017, 4:42 PM
Hahnfeld edited edge metadata.Jan 9 2017, 11:23 PM

Will you (as the bot owner) take care that /home/bbot/opt/clang is updated?

Ideally I think libomp should be built together with a full LLVM stack. So, building llvm + clang + openmp for all commits to these subprojects.

This would
a) enable us to catch regressions in clang itself because the libomp (and libomptarget in the future) tests are triggered for each commit to clang
b) remove the necessity to rebuild clang separately for each commit to libomp which is quite time consuming and doesn't give full coverage of all commits to clang.

Hi Jonas

Will you (as the bot owner) take care that /home/bbot/opt/clang is updated?

The version of clang in /home/bbot/opt/clang is last clang release and it is the stable c/c++ compiler in the machine. I expect to update it when a new release is available.

Ideally I think libomp should be built together with a full LLVM stack. So, building llvm + clang + openmp for all commits to these subprojects.

This would
a) enable us to catch regressions in clang itself because the libomp (and libomptarget in the future) tests are triggered for each commit to clang
b) remove the necessity to rebuild clang separately for each commit to libomp which is quite time consuming and doesn't give full coverage of all commits to clang.

I agree. I think that we should also have separate in-tree and standalone builds for openmp given that there is a lot of stuff in the build system that depends on that. In summary:
i) llvm+clang+openmp in tree build with machine stable compiler
ii) standalone openmp build with the compiler built in i)
iii) standalone openmp build with the machine stable compiler

We could skip iii), but it is a fairly quick build. I don't mind working on a patch to do this on ppc64le-nvidia-K40. Was there any discussion to do that on the existing slave?

Thanks,
Samuel

I agree. I think that we should also have separate in-tree and standalone builds for openmp given that there is a lot of stuff in the build system that depends on that. In summary:
i) llvm+clang+openmp in tree build with machine stable compiler
ii) standalone openmp build with the compiler built in i)
iii) standalone openmp build with the machine stable compiler

Why do we need ii)? i) will use the just-built compiler to test the openmp runtime AFAIK

We could skip iii), but it is a fairly quick build. I don't mind working on a patch to do this on ppc64le-nvidia-K40. Was there any discussion to do that on the existing slave?

Thanks,
Samuel

There was some discussion last year but I think nothing has happened so far :-/ http://lists.llvm.org/pipermail/openmp-dev/2016-March/001179.html

Why do we need ii)? i) will use the just-built compiler to test the openmp runtime AFAIK

The reason I am proposing ii) is to test the build of the library itself. Making sure the library build without issues with the latest clang would be something good to have. In terms of the runtime tests, they would basically use similar builds but exercising different logic in the build system.

Thanks,
Samuel

Why do we need ii)? i) will use the just-built compiler to test the openmp runtime AFAIK

The reason I am proposing ii) is to test the build of the library itself. Making sure the library build without issues with the latest clang would be something good to have. In terms of the runtime tests, they would basically use similar builds but exercising different logic in the build system.

Thanks,
Samuel

Ok, SGTM

sfantao closed this revision.Jan 10 2017, 8:22 AM