Reducing LLVM closure size

Reducing LLVM closure size

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 2496 bytes --]

Since LLVM is all over the place, _multiple_ versions of LLVM inevitably
end up in anyone's graph.

Can we reduce its closure size?

--8<---------------cut here---------------start------------->8---
> guix size llvm
store item                                                       total    self
/gnu/store/118xpdazyylxa1rlc68h9lmh38vhxrb4-llvm-10.0.0            210.8   139.3  66.1%
/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31              38.4    36.7  17.4%
/gnu/store/01b4w3m6mp55y531kyi1g8shh722kwqm-gcc-7.5.0-lib           71.0    32.6  15.5%
/gnu/store/mmhimfwmmidf09jw1plw3aw1g1zn2nkh-bash-static-5.0.16       1.6     1.6   0.8%
/gnu/store/rykm237xkmq7rl1p0nwass01p090p88x-zlib-1.2.11             71.2     0.2   0.1%
/gnu/store/bw15z9kh9c65ycc2vbhl2izwfwfva7p1-libffi-3.3              71.2     0.2   0.1%
total: 210.8 MiB
--8<---------------cut here---------------end--------------->8---

Let's look at what Arch Linux does:

- https://www.archlinux.org/packages/extra/x86_64/llvm/
- https://www.archlinux.org/packages/extra/x86_64/llvm-libs/
- https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/llvm

For the first 2 links, click on
"View the file list for ..." link at the bottom to display the file
list.

"bin" and "include" occupy some 35 MiB.  First thing we can do is split

- either move the libs to a "lib" output,
- or move the "bin" and "include" folder to a new output.

The second approach has the benefit of being less disruptive for dependents.

Now if we look at the PKGBUILD, there are some interesting compilation
flags.  If we remove

  "-DBUILD_SHARED_LIBS:BOOL=TRUE"

and add

  "-DLLVM_BUILD_LLVM_DYLIB=ON"
  "-DLLVM_LINK_LLVM_DYLIB=ON"

it will produce a single libLLVM-10.so library.  This reduces the "lib"
folder size from 107 MiB to 90 MiB.

All in all, it looks like we can save 52 MiB out of 140 MiB from the LLVM
package (and 210 MiB from its closure).

This would need a bit of testing since LLVM has many versions and many
dependents (a change to llvm-3 rebuilds 1000+ dependents).

By the way, this looks like a bug:

--8<---------------cut here---------------start------------->8---
> guix refresh -l llvm
Building the following package would ensure 3 dependent packages are rebuilt: clang-toolchain@10.0.0
--8<---------------cut here---------------end--------------->8---

Why is only 1 package displayed?

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Reducing LLVM closure size

[Julien Lepiller]

Le 12 juin 2020 05:06:32 GMT-04:00, Pierre Neidhardt <mail@ambrevar.xyz> a écrit : 
>
>By the way, this looks like a bug:
>
>--8<---------------cut here---------------start------------->8---
>> guix refresh -l llvm
>Building the following package would ensure 3 dependent packages are
>rebuilt: clang-toolchain@10.0.0
>--8<---------------cut here---------------end--------------->8---
>
>Why is only 1 package displayed?

Because these are the dependants for llvm@10, but the default llvm is llvm@9:

guix refresh -l llvm@9
Building the following 1180 packages would ensure 2092 lependent packages are rebuilt: …

That's not on latest master, so your numbers can vary a bit.

Re: Reducing LLVM closure size

[Oliver Propst]

[-- Attachment #1: Type: text/plain, Size: 941 bytes --]

Well I think regardless that Pierre's efforts are very good and should
be encouraged.


On Fri, Jun 12, 2020 at 2:02 PM Julien Lepiller <julien@lepiller.eu> wrote:

> Le 12 juin 2020 05:06:32 GMT-04:00, Pierre Neidhardt <mail@ambrevar.xyz>
> a écrit :
> >
> >By the way, this looks like a bug:
> >
> >--8<---------------cut here---------------start------------->8---
> >> guix refresh -l llvm
> >Building the following package would ensure 3 dependent packages are
> >rebuilt: clang-toolchain@10.0.0
> >--8<---------------cut here---------------end--------------->8---
> >
> >Why is only 1 package displayed?
>
> Because these are the dependants for llvm@10, but the default llvm is
> llvm@9:
>
> guix refresh -l llvm@9
> Building the following 1180 packages would ensure 2092 lependent packages
> are rebuilt: …
>
> That's not on latest master, so your numbers can vary a bit.
>
>

-- 
-mvh Oliver Propst

[-- Attachment #2: Type: text/html, Size: 1442 bytes --]

Re: Reducing LLVM closure size

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 740 bytes --]

Julien Lepiller <julien@lepiller.eu> writes:

>>By the way, this looks like a bug:
>>
>>--8<---------------cut here---------------start------------->8---
>>> guix refresh -l llvm
>>Building the following package would ensure 3 dependent packages are
>>rebuilt: clang-toolchain@10.0.0
>>--8<---------------cut here---------------end--------------->8---
>>
>>Why is only 1 package displayed?
>
> Because these are the dependants for llvm@10, but the default llvm is llvm@9:
>
> guix refresh -l llvm@9
> Building the following 1180 packages would ensure 2092 lependent packages are rebuilt: …

This does not explain why it says "3 dependent packages" but lists only
one! :)

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Reducing LLVM closure size

[Julien Lepiller]

Le 12 juin 2020 09:19:48 GMT-04:00, Pierre Neidhardt <mail@ambrevar.xyz> a écrit :
>Julien Lepiller <julien@lepiller.eu> writes:
>
>>>By the way, this looks like a bug:
>>>
>>>--8<---------------cut here---------------start------------->8---
>>>> guix refresh -l llvm
>>>Building the following package would ensure 3 dependent packages are
>>>rebuilt: clang-toolchain@10.0.0
>>>--8<---------------cut here---------------end--------------->8---
>>>
>>>Why is only 1 package displayed?
>>
>> Because these are the dependants for llvm@10, but the default llvm is
>llvm@9:
>>
>> guix refresh -l llvm@9
>> Building the following 1180 packages would ensure 2092 lependent
>packages are rebuilt: …
>
>This does not explain why it says "3 dependent packages" but lists only
>one! :)

Because building this one will also rebuild the other two, re-read the sentence carefully :)

llvm -> clang -> clang-toolchain

Re: Reducing LLVM closure size

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 241 bytes --]

Julien Lepiller <julien@lepiller.eu> writes:

> Because building this one will also rebuild the other two, re-read the sentence carefully :)
>
> llvm -> clang -> clang-toolchain

Oh! :D

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Reducing LLVM closure size

[Arun Isaac]

[-- Attachment #1: Type: text/plain, Size: 188 bytes --]


> Since LLVM is all over the place, _multiple_ versions of LLVM inevitably
> end up in anyone's graph.

Is it possible to build a full system completely avoiding LLVM and only
using GCC?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Reducing LLVM closure size

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 115 bytes --]

I believe many programs including Mesa explicitly depend on LLVM.

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Reducing LLVM closure size

[Ludovic Courtès]

Hi,

Pierre Neidhardt <mail@ambrevar.xyz> skribis:

> For the first 2 links, click on
> "View the file list for ..." link at the bottom to display the file
> list.
>
> "bin" and "include" occupy some 35 MiB.  First thing we can do is split
>
> - either move the libs to a "lib" output,
> - or move the "bin" and "include" folder to a new output.
>
> The second approach has the benefit of being less disruptive for dependents.

I have a slight preference for a “lib” output since that’s more in line
with what we do for other packages.

> Now if we look at the PKGBUILD, there are some interesting compilation
> flags.  If we remove
>
>   "-DBUILD_SHARED_LIBS:BOOL=TRUE"
>
> and add
>
>   "-DLLVM_BUILD_LLVM_DYLIB=ON"
>   "-DLLVM_LINK_LLVM_DYLIB=ON"
>
> it will produce a single libLLVM-10.so library.  This reduces the "lib"
> folder size from 107 MiB to 90 MiB.

Nice!  I looked for something like this when I packaged
‘clang-tools-extra’ and didn’t find it.  This should go into the next
‘staging’ branch (or ‘core-updates’?).

> All in all, it looks like we can save 52 MiB out of 140 MiB from the LLVM
> package (and 210 MiB from its closure).

That’d be great.

An additional option would be to have a package with fewer backends by
default (currently all of them are enabled and that takes up quite some
space).  In particular, Mesa doesn’t depend to depend on an LLVM variant
with 15 backends when it’s only going to use one.

Thanks,
Ludo’.

Re: Reducing LLVM closure size

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 1940 bytes --]

Ludovic Courtès <ludo@gnu.org> writes:

>> - either move the libs to a "lib" output,
>> - or move the "bin" and "include" folder to a new output.
>>
>> The second approach has the benefit of being less disruptive for dependents.
>
> I have a slight preference for a “lib” output since that’s more in line
> with what we do for other packages.

OK.

> Nice!  I looked for something like this when I packaged
> ‘clang-tools-extra’ and didn’t find it.  This should go into the next
> ‘staging’ branch (or ‘core-updates’?).

I can send a patch for llvm-10, but I guess many llvm-dependents will
have to be updated accordingly.

I suppose that the input

--8<---------------cut here---------------start------------->8---
("llvm" ,llvm)
--8<---------------cut here---------------end--------------->8---

will need to be turned to

--8<---------------cut here---------------start------------->8---
("llvm" ,llvm "lib")
--8<---------------cut here---------------end--------------->8---

for most packages.  I have no experience with LLVM, so can someone
confirm that this is the right way to go?

>> All in all, it looks like we can save 52 MiB out of 140 MiB from the LLVM
>> package (and 210 MiB from its closure).
>
> That’d be great.

To clarify the ambiguous sentence I wrote above, we would save 52 MiB
from the closure size of LLVM.

> An additional option would be to have a package with fewer backends by
> default (currently all of them are enabled and that takes up quite some
> space).  In particular, Mesa doesn’t depend to depend on an LLVM variant
> with 15 backends when it’s only going to use one.

Are you suggesting an alternative or a tweak to add on top of my
suggestion?

Where would we store the different backends?  In different outputs?
On which backend does Mesa depend for instance?

Cheers!

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Reducing LLVM closure size

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 2483 bytes --]

On Tue, Jun 16, 2020 at 11:27:45AM +0200, Pierre Neidhardt wrote:
> Ludovic Courtès <ludo@gnu.org> writes:
> 
> >> - either move the libs to a "lib" output,
> >> - or move the "bin" and "include" folder to a new output.
> >>
> >> The second approach has the benefit of being less disruptive for dependents.
> >
> > I have a slight preference for a “lib” output since that’s more in line
> > with what we do for other packages.
> 
> OK.
> 

I see the include directory is about 20MB, can that be left in "out" or
is that needed in the "lib" output?

> > Nice!  I looked for something like this when I packaged
> > ‘clang-tools-extra’ and didn’t find it.  This should go into the next
> > ‘staging’ branch (or ‘core-updates’?).
> 
> I can send a patch for llvm-10, but I guess many llvm-dependents will
> have to be updated accordingly.
> 
> I suppose that the input
> 
> --8<---------------cut here---------------start------------->8---
> ("llvm" ,llvm)
> --8<---------------cut here---------------end--------------->8---
> 
> will need to be turned to
> 
> --8<---------------cut here---------------start------------->8---
> ("llvm" ,llvm "lib")
> --8<---------------cut here---------------end--------------->8---
> 
> for most packages.  I have no experience with LLVM, so can someone
> confirm that this is the right way to go?
> 
> >> All in all, it looks like we can save 52 MiB out of 140 MiB from the LLVM
> >> package (and 210 MiB from its closure).
> >
> > That’d be great.
> 
> To clarify the ambiguous sentence I wrote above, we would save 52 MiB
> from the closure size of LLVM.
> 
> > An additional option would be to have a package with fewer backends by
> > default (currently all of them are enabled and that takes up quite some
> > space).  In particular, Mesa doesn’t depend to depend on an LLVM variant
> > with 15 backends when it’s only going to use one.
> 
> Are you suggesting an alternative or a tweak to add on top of my
> suggestion?
> 
> Where would we store the different backends?  In different outputs?
> On which backend does Mesa depend for instance?

I would assume llvmpipe

> 
> Cheers!
> 
> -- 
> Pierre Neidhardt
> https://ambrevar.xyz/



-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Reducing LLVM closure size

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 441 bytes --]

Efraim Flashner <efraim@flashner.co.il> writes:

> I see the include directory is about 20MB, can that be left in "out" or
> is that needed in the "lib" output?

It can be left out, I mentioned it in my first email.

>> Where would we store the different backends?  In different outputs?
>> On which backend does Mesa depend for instance?
>
> I would assume llvmpipe

OK, thanks!

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Reducing LLVM closure size

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 1000 bytes --]

Hi!

Pierre Neidhardt <mail@ambrevar.xyz> writes:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Nice!  I looked for something like this when I packaged
>> ‘clang-tools-extra’ and didn’t find it.  This should go into the next
>> ‘staging’ branch (or ‘core-updates’?).
>
> I can send a patch for llvm-10, but I guess many llvm-dependents will
> have to be updated accordingly.
>
> I suppose that the input
>
> --8<---------------cut here---------------start------------->8---
> ("llvm" ,llvm)
> --8<---------------cut here---------------end--------------->8---
>
> will need to be turned to
>
> --8<---------------cut here---------------start------------->8---
> ("llvm" ,llvm "lib")
> --8<---------------cut here---------------end--------------->8---
>
> for most packages.  I have no experience with LLVM, so can someone
> confirm that this is the right way to go?

Friendly ping :)
Should I send a patch?

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Reducing LLVM closure size

[Ludovic Courtès]

Hi,

Pierre Neidhardt <mail@ambrevar.xyz> skribis:

> Pierre Neidhardt <mail@ambrevar.xyz> writes:
>
>> Ludovic Courtès <ludo@gnu.org> writes:
>>
>>> Nice!  I looked for something like this when I packaged
>>> ‘clang-tools-extra’ and didn’t find it.  This should go into the next
>>> ‘staging’ branch (or ‘core-updates’?).
>>
>> I can send a patch for llvm-10, but I guess many llvm-dependents will
>> have to be updated accordingly.
>>
>> I suppose that the input
>>
>> --8<---------------cut here---------------start------------->8---
>> ("llvm" ,llvm)
>> --8<---------------cut here---------------end--------------->8---
>>
>> will need to be turned to
>>
>> --8<---------------cut here---------------start------------->8---
>> ("llvm" ,llvm "lib")
>> --8<---------------cut here---------------end--------------->8---
>>
>> for most packages.  I have no experience with LLVM, so can someone
>> confirm that this is the right way to go?
>
> Friendly ping :)
> Should I send a patch?

Yes, please!

Ludo’.

Re: Reducing LLVM closure size

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 302 bytes --]

Efraim Flashner <efraim@flashner.co.il> writes:

>> Where would we store the different backends?  In different outputs?
>> On which backend does Mesa depend for instance?
>
> I would assume llvmpipe

Actually what is llvmpipe?  I cannot find it.

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Reducing LLVM closure size

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 236 bytes --]

Partially done:

42576@debbugs.gnu.org

It's not working at the moment because header files are still referenced
in the dependents .so.  Any idea how to work around this?

Cheers!

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]