llvm dev - Jan 2017 - Your help needed: List of LLVM Open Projects 2017

On 16 January 2017 at 15:31, Sean Silva <chisophugis at gmail.com>
wrote:
> Do we have any open projects on LLD?
>
> I know we usually try to avoid any big "projects" and mainly
add/fix things
> in response to user needs, but just wondering if somebody has any ideas.
>
> Some really generic/simple stuff I can think of:
> 1. trying out LLD on a large program corpus and reporting/reducing/fixing
> bugs (e.g. contributing to the FreeBSD effort or trying to build a bunch of
> packages from a linux distro like Debian or Gentoo)
>From Rafael's last Poudriere ports build I think about 98% of the
packages are building with LLD, and some of the missing ones are those
that were skipped (e.g. do not build on amd64, or the upstream
distfiles have gone away). I think some next steps here for FreeBSD
include:

* Ensure we're running the test suites in packages that have them
* Actually install and use the resulting packages for a smoke test
* Address the WIP patches / workarounds currently in use
* Triage the few hundred failures
>From the FreeBSD perspective there's one key LLD task of interest:
* Bring other architecture support to parity with amd64/x86_64. For us
the next one in importance is AArch64/arm64, then i386 and 32-bit arm,
and 32- and 64-bit MIPS, PowerPC, and RISC-V.

On Mon, Jan 16, 2017 at 1:17 PM, Ed Maste <emaste at freebsd.org> wrote:
> On 16 January 2017 at 15:31, Sean Silva <chisophugis at gmail.com>
wrote:
> > Do we have any open projects on LLD?
> >
> > I know we usually try to avoid any big "projects" and mainly
add/fix
> things
> > in response to user needs, but just wondering if somebody has any
ideas.
> >
> > Some really generic/simple stuff I can think of:
> > 1. trying out LLD on a large program corpus and
reporting/reducing/fixing
> > bugs (e.g. contributing to the FreeBSD effort or trying to build a
bunch
> of
> > packages from a linux distro like Debian or Gentoo)
>
> From Rafael's last Poudriere ports build I think about 98% of the
> packages are building with LLD, and some of the missing ones are those
> that were skipped (e.g. do not build on amd64, or the upstream
> distfiles have gone away).

I thought most of the skipped stuff was due to dependencies on packages
that failed? Or is that no longer the case?

> I think some next steps here for FreeBSD
> include:
>
> * Ensure we're running the test suites in packages that have them
> * Actually install and use the resulting packages for a smoke test
> * Address the WIP patches / workarounds currently in use
>
Are these collected somewhere / is there a status page to reference?

> * Triage the few hundred failures
>
Are these collected somewhere / is there a status page to reference?

>
> From the FreeBSD perspective there's one key LLD task of interest:
>
> * Bring other architecture support to parity with amd64/x86_64. For us
> the next one in importance is AArch64/arm64, then i386 and 32-bit arm,
> and 32- and 64-bit MIPS, PowerPC, and RISC-V.
>
Architecture porting might be challenging for new contributors, since the
will usually require access to "unusual" hardware, right? Or are there
emulator options available? If so, it would be good to document those
options because it will greatly expand the number of people that can work
on these tasks.

-- Sean Silva
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170116/c46a12b2/attachment.html>

On 16 January 2017 at 16:33, Sean Silva <chisophugis at gmail.com>
wrote:
>
> I thought most of the skipped stuff was due to dependencies on packages
that
> failed? Or is that no longer the case?
Skipped packages are all ones with a dependency did not build, either
because the dependent package tried and failed to build, or because
the dependent package is not supported on the architecture, is marked
in the port metatadata as broken, etc.

With an unmodified LLD and unmodified FreeBSD ports tree a couple of
packages fail because of libtool, and other packages fail because of
an issue with DTrace. Most of the skipped packages in such a run are
due to those failed packages. Rafael worked around it in his Poudriere
run by adding "not GNU" to the LLD version string and another similar
change, and adding a workaround for DTrace. I've been looking at
trying to fix libtool but upstream is not very responsive, and Mark
Johnston is working on fixing DTrace.

We also have some work in progress against the FreeBSD ports tree. The
"about 98%" number is with the workarounds and WIP in place, and
we're
under 300 failures. Most of those are leaf ports with no downstream
dependencies. There's a small number of failures (around 5) each
responsible for between 10 and 100 skipped or so.
>> I think some next steps here for FreeBSD
>> include:
>>
>> * Ensure we're running the test suites in packages that have them
>> * Actually install and use the resulting packages for a smoke test
>> * Address the WIP patches / workarounds currently in use
>> * Triage the few hundred failures
>
> Are these collected somewhere / is there a status page to reference?
The workarounds in the FreeBSD ports tree are here:
https://github.com/emaste/freebsd-ports/commits/ports-lld

A while back Rafael posted the LLD patch he's using to the list. I
will try to find these details and start a status page on the FreeBSD
wiki.