Sean Silva
2013-Nov-14 02:17 UTC
[LLVMdev] Quad-Core ARMv7 Build Slave Seeks Noble Purpose
On Wed, Nov 13, 2013 at 8:48 PM, Dmitri Gribenko <gribozavr at gmail.com>wrote:> On Wed, Nov 13, 2013 at 5:28 PM, Mikael Lyngvig <mikael at lyngvig.org> > wrote: > > Hi Dmitri, > > > > I am not using any kind of cache (didn't even know of ccache). I have > now > > installed ccache. Perhaps ccache should be mentioned in the buildbot > > document so that every buildbot owner knows about it? > > Possibly. > > > It is currently running Arch Linux ARM. if there are good reasons to > switch > > to something else, I'll be happy to do that, although I am generally very > > happy about Arch Linux. > > > > What do you want me to build? LLVM? Clang? Both plus test suite? > > Personally, I see more value in building LLVM, Clang, possibly lld, >I think LLD would especially benefit from testing on other architectures, since LLD is the most prone to accidentally having something architecture-dependent (e.g. assuming pointers are 64 bits, endianness, alignment, etc) and so testing it on more architectures will turn up bugs. -- Sean Silva> without test suite. This is the way that most build bots operate. > Test suite takes a long time to run, and this increases the iteration > time. > > As an example, you could look at the configuration in zorg repository > that corresponds to this buildbot: > > http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-debian-fast > > It uses CMake/ninja, which will give you the best possible iteration time. > > In order to use ccache, you need ensure that these environment > variables are set: > > CC="ccache clang" > CXX="ccache clang++" > CCACHE_CPP2=yes > export CC CXX CCACHE_CPP2 > > (Of course, you can use gcc/g++ as compilers.) > > Dmitri > > -- > main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if > (j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/ > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131113/a30ad0b3/attachment.html>
Nick Kledzik
2013-Nov-14 03:31 UTC
[LLVMdev] Quad-Core ARMv7 Build Slave Seeks Noble Purpose
On Nov 13, 2013, at 6:17 PM, Sean Silva <chisophugis at gmail.com> wrote:> > What do you want me to build? LLVM? Clang? Both plus test suite? > > Personally, I see more value in building LLVM, Clang, possibly lld, > > I think LLD would especially benefit from testing on other architectures, since LLD is the most prone to accidentally having something architecture-dependent (e.g. assuming pointers are 64 bits, endianness, alignment, etc) and so testing it on more architectures will turn up bugs.Yes, lld reads binary files so gets all the potential bugs that comes with that. Mach-O binary format is challenging because it uses bit fields structs and the compiler switches the direction of bit fields on big vs little endian archs! That said, isn’t the ARM machine 32-bit little endian? Other than possible alignment issues, it has the same coverage as i386. What lld needs is big endian build machines. -Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131113/75e31ead/attachment.html>
Sean Silva
2013-Nov-14 03:38 UTC
[LLVMdev] Quad-Core ARMv7 Build Slave Seeks Noble Purpose
On Wed, Nov 13, 2013 at 10:31 PM, Nick Kledzik <kledzik at apple.com> wrote:> > On Nov 13, 2013, at 6:17 PM, Sean Silva <chisophugis at gmail.com> wrote: > > > What do you want me to build? LLVM? Clang? Both plus test suite? >> >> Personally, I see more value in building LLVM, Clang, possibly lld, >> > > I think LLD would especially benefit from testing on other architectures, > since LLD is the most prone to accidentally having something > architecture-dependent (e.g. assuming pointers are 64 bits, endianness, > alignment, etc) and so testing it on more architectures will turn up bugs. > > > Yes, lld reads binary files so gets all the potential bugs that comes with > that. Mach-O binary format is challenging because it uses bit fields > structs and the compiler switches the direction of bit fields on big vs > little endian archs! >Ouch...> > That said, isn’t the ARM machine 32-bit little endian? Other than > possible alignment issues, it has the same coverage as i386. What lld > needs is big endian build machines. >Yeah, big endian would really be nice (ppc, sparc? we must have *some* big-endian builders...), but just the alignment checking is still a worthwhile step up from the status quo I think (although IIRC UBSan also catches these?). -- Sean Silva> > -Nick > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131113/e0f256c4/attachment.html>
Mikael Lyngvig
2013-Nov-14 03:40 UTC
[LLVMdev] Quad-Core ARMv7 Build Slave Seeks Noble Purpose
Yes, ARM normally runs as a little-endian and it is a 32-bit CPU. It CAN be configured to be a big-endian system, but that requires hardware support as far as I know. I do have an old, slow Mac Mini G4 PowerPC (big-endian) that I could hook up as a builder too. I was thinking of it the moment you mentioned big endian. I actually bought it for testing C++ code on because big-endian machines are so great at catching those silly errors that we little-endianers occasionally do. -- Mikael 2013/11/14 Nick Kledzik <kledzik at apple.com>> > On Nov 13, 2013, at 6:17 PM, Sean Silva <chisophugis at gmail.com> wrote: > > > What do you want me to build? LLVM? Clang? Both plus test suite? >> >> Personally, I see more value in building LLVM, Clang, possibly lld, >> > > I think LLD would especially benefit from testing on other architectures, > since LLD is the most prone to accidentally having something > architecture-dependent (e.g. assuming pointers are 64 bits, endianness, > alignment, etc) and so testing it on more architectures will turn up bugs. > > > Yes, lld reads binary files so gets all the potential bugs that comes with > that. Mach-O binary format is challenging because it uses bit fields > structs and the compiler switches the direction of bit fields on big vs > little endian archs! > > That said, isn’t the ARM machine 32-bit little endian? Other than > possible alignment issues, it has the same coverage as i386. What lld > needs is big endian build machines. > > -Nick > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131114/d0ac72c0/attachment.html>
Seemingly Similar Threads
- [LLVMdev] Quad-Core ARMv7 Build Slave Seeks Noble Purpose
- [LLVMdev] Quad-Core ARMv7 Build Slave Seeks Noble Purpose
- [LLVMdev] Quad-Core ARMv7 Build Slave Seeks Noble Purpose
- [LLVMdev] Quad-Core ARMv7 Build Slave Seeks Noble Purpose
- [LLVMdev] Quad-Core ARMv7 Build Slave Seeks Noble Purpose