llvm dev - Nov 2021 - Preparing BOLT for LLVM monorepo

> Making sure things are LLVM coding style, format, etc are pretty
> important to me. flang was a useful pilot here in a lot of ways and some
> of the requests for fixups still don't really seem to have happened so
> making sure that happens before is pretty important to me.
Following someone's footsteps has its drawbacks too :) Fair enough. We
continue to develop BOLT and have plans for more tight integration with
LLVM, such as sharing the common binary IR. Having a clean and
easy-to-read codebase will be highly beneficial to the community.
>> We haven't made the final decision on including BOLT in
>> LLVM_ALL_PROJECTS, but we are ready to make BOLT the default project in
>> the initial merge commit. Currently, we do not support building on
>> Windows; thus, the project will be automatically disabled with the
>> warning when building on unsupported platforms. As we anticipate the
>
> Oh? Build or work? And why :)
The Windows build was disabled due to the usage of threads, IIRC.
Although, we don't use them directly, only via the C++11 standard
library. I don't have access to a windows box to test it myself. If the
build issues are resolved, I don't see why BOLT can't be used to
optimize ELF binaries on windows.

Thanks!
Maksim

On 11/2/21, 3:15 PM, "Eric Christopher" <echristo at gmail.com>
wrote:

Hi Maksim,

I think this sounds great in general.

Making sure things are LLVM coding style, format, etc are pretty important to
me. flang was a useful pilot here in a lot of ways and some of the requests for
fixups still don't really seem to have happened so making sure that happens
before is pretty important to me.

One inline question:

We haven't made the final decision on including BOLT in
LLVM_ALL_PROJECTS, but we are ready to make BOLT the default project in
the initial merge commit. Currently, we do not support building on
Windows; thus, the project will be automatically disabled with the
warning when building on unsupported platforms. As we anticipate the


Oh? Build or work? And why :)

Thanks and good luck!

-eric

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20211103/085f4ba2/attachment.html>

On Wed, Nov 3, 2021 at 2:37 AM Maksim Panchenko <maks at fb.com> wrote:
> > Making sure things are LLVM coding style, format, etc are pretty
>
> > important to me. flang was a useful pilot here in a lot of ways and
some
>
> > of the requests for fixups still don't really seem to have
happened so
>
> > making sure that happens before is pretty important to me.
>
>
>
> Following someone's footsteps has its drawbacks too :) Fair enough. We
>
> continue to develop BOLT and have plans for more tight integration with
>
> LLVM, such as sharing the common binary IR. Having a clean and
>
> easy-to-read codebase will be highly beneficial to the community.
>
>
>
Excellent. Looking forward to the code review!

> >> We haven't made the final decision on including BOLT in
>
> >> LLVM_ALL_PROJECTS, but we are ready to make BOLT the default
project in
>
> >> the initial merge commit. Currently, we do not support building on
>
> >> Windows; thus, the project will be automatically disabled with the
>
> >> warning when building on unsupported platforms. As we anticipate
the
>
> >
>
> > Oh? Build or work? And why :)
>
>
>
> The Windows build was disabled due to the usage of threads, IIRC.
>
> Although, we don't use them directly, only via the C++11 standard
>
> library. I don't have access to a windows box to test it myself. If the
>
> build issues are resolved, I don't see why BOLT can't be used to
>
> optimize ELF binaries on windows.
>
>
>
Makes sense. Might be good to just disable threads on windows rather than
disabling the build also.

Thanks for the response!

-eric

> Thanks!
>
> Maksim
>
>
>
> On 11/2/21, 3:15 PM, "Eric Christopher" <echristo at
gmail.com> wrote:
>
>
>
> Hi Maksim,
>
>
>
> I think this sounds great in general.
>
>
>
> Making sure things are LLVM coding style, format, etc are pretty important
> to me. flang was a useful pilot here in a lot of ways and some of the
> requests for fixups still don't really seem to have happened so making
sure
> that happens before is pretty important to me.
>
>
>
> One inline question:
>
>
>
> We haven't made the final decision on including BOLT in
>
> LLVM_ALL_PROJECTS, but we are ready to make BOLT the default project in
>
> the initial merge commit. Currently, we do not support building on
>
> Windows; thus, the project will be automatically disabled with the
>
> warning when building on unsupported platforms. As we anticipate the
>
>
>
>
>
> Oh? Build or work? And why :)
>
>
>
> Thanks and good luck!
>
>
>
> -eric
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20211103/2300e1b4/attachment-0001.html>

On Tue, Nov 2, 2021 at 11:37 PM Maksim Panchenko <maks at fb.com> wrote:
> > Making sure things are LLVM coding style, format, etc are pretty
>
> > important to me. flang was a useful pilot here in a lot of ways and
some
>
> > of the requests for fixups still don't really seem to have
happened so
>
> > making sure that happens before is pretty important to me.
>
>
>
> Following someone's footsteps has its drawbacks too :) Fair enough. We
>
> continue to develop BOLT and have plans for more tight integration with
>
> LLVM, such as sharing the common binary IR. Having a clean and
>
> easy-to-read codebase will be highly beneficial to the community.
>
>
>
> >> We haven't made the final decision on including BOLT in
>
> >> LLVM_ALL_PROJECTS, but we are ready to make BOLT the default
project in
>
> >> the initial merge commit. Currently, we do not support building on
>
> >> Windows; thus, the project will be automatically disabled with the
>
> >> warning when building on unsupported platforms. As we anticipate
the
>
> >
>
> > Oh? Build or work? And why :)
>
>
>
> The Windows build was disabled due to the usage of threads, IIRC.
>
> Although, we don't use them directly, only via the C++11 standard
>
> library. I don't have access to a windows box to test it myself.
>
Have you folks been trying to use the threading APIs exposed by libSupport?
They are supposed to work on Windows as well (at least I think lld makes
use it these and works on Windows)


If the
>
> build issues are resolved, I don't see why BOLT can't be used to
>
> optimize ELF binaries on windows.
>
>
>
> Thanks!
>
> Maksim
>
>
>
> On 11/2/21, 3:15 PM, "Eric Christopher" <echristo at
gmail.com> wrote:
>
>
>
> Hi Maksim,
>
>
>
> I think this sounds great in general.
>
>
>
> Making sure things are LLVM coding style, format, etc are pretty important
> to me. flang was a useful pilot here in a lot of ways and some of the
> requests for fixups still don't really seem to have happened so making
sure
> that happens before is pretty important to me.
>
>
>
> One inline question:
>
>
>
> We haven't made the final decision on including BOLT in
>
> LLVM_ALL_PROJECTS, but we are ready to make BOLT the default project in
>
> the initial merge commit. Currently, we do not support building on
>
> Windows; thus, the project will be automatically disabled with the
>
> warning when building on unsupported platforms. As we anticipate the
>
>
>
>
>
> Oh? Build or work? And why :)
>
>
>
> Thanks and good luck!
>
>
>
> -eric
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20211103/c43711cf/attachment.html>

On Wed, 3 Nov 2021, Maksim Panchenko via llvm-dev wrote:
> The Windows build was disabled due to the usage of threads, IIRC.
> Although, we don't use them directly, only via the C++11 standard
> library. I don't have access to a windows box to test it myself.
C++11 threads should be usable on Windows too, in general.

If building with GCC/libstdc++, there's two compiler configurations, the 
"win32 thread model" which doesn't provide the full C++11 thread
support,
and the "posix thread model" which is configured to run libgcc and 
libstdc++ on top of libwinpthread, which does support C++11 threads. I 
suspect this is what you've run into.

The mingw cross compilers in debian/ubuntu ship both configurations, but 
default to the "win32 thread model" without libwinpthread. There, you
can
choose the other one by invoking e.g. "x86_64-w64-mingw32-g++-posix",
i.e.
there are compiler frontends with -win32 and -posix suffixes in addition 
to the default.

I think the LLVM codebase also uses some bits of C++11 threads/mutexes 
somewhere, because I remember that cross compiling LLVM with the 
debian/ubuntu provided mingw compilers requires using the -posix suffixed 
tools. So with that in mind, this shouldn't be any additional limitation 
compared with what LLVM requires already.

Also, if building for Windows with a toolchain that uses libc++ (which is 
also usable in mingw configurations) or MSVC STL, then there's no 
ambiguity, C++11 threads are always available.

// Martin