<feed xmlns='http://www.w3.org/2005/Atom'>
<title>bcm5719-llvm/llvm/lib/Target/AArch64/AsmParser, branch meklort-10.0.1</title>
<subtitle>Project Ortega BCM5719 LLVM</subtitle>
<id>https://git.raptorcs.com/git/bcm5719-llvm/atom?h=meklort-10.0.1</id>
<link rel='self' href='https://git.raptorcs.com/git/bcm5719-llvm/atom?h=meklort-10.0.1'/>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/bcm5719-llvm/'/>
<updated>2020-01-15T03:46:52+00:00</updated>
<entry>
<title>CMake: Make most target symbols hidden by default</title>
<updated>2020-01-15T03:46:52+00:00</updated>
<author>
<name>Tom Stellard</name>
<email>tstellar@redhat.com</email>
</author>
<published>2020-01-15T03:15:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/bcm5719-llvm/commit/?id=0dbcb3639451a7c20e2d5133b459552281e64455'/>
<id>urn:sha1:0dbcb3639451a7c20e2d5133b459552281e64455</id>
<content type='text'>
Summary:
For builds with LLVM_BUILD_LLVM_DYLIB=ON and BUILD_SHARED_LIBS=OFF
this change makes all symbols in the target specific libraries hidden
by default.

A new macro called LLVM_EXTERNAL_VISIBILITY has been added to mark symbols in these
libraries public, which is mainly needed for the definitions of the
LLVMInitialize* functions.

This patch reduces the number of public symbols in libLLVM.so by about
25%.  This should improve load times for the dynamic library and also
make abi checker tools, like abidiff require less memory when analyzing
libLLVM.so

One side-effect of this change is that for builds with
LLVM_BUILD_LLVM_DYLIB=ON and LLVM_LINK_LLVM_DYLIB=ON some unittests that
access symbols that are no longer public will need to be statically linked.

Before and after public symbol counts (using gcc 8.2.1, ld.bfd 2.31.1):
nm before/libLLVM-9svn.so | grep ' [A-Zuvw] ' | wc -l
36221
nm after/libLLVM-9svn.so | grep ' [A-Zuvw] ' | wc -l
26278

Reviewers: chandlerc, beanz, mgorny, rnk, hans

Reviewed By: rnk, hans

Subscribers: merge_guards_bot, luismarques, smeenai, ldionne, lenary, s.egerton, pzheng, sameer.abuasal, MaskRay, wuzish, echristo, Jim, hiraditya, michaelplatings, chapuni, jholewinski, arsenm, dschuff, jyknight, dylanmckay, sdardis, nemanjai, jvesely, javed.absar, sbc100, jgravelle-google, aheejin, kbarton, fedor.sergeev, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, zzheng, edward-jones, mgrang, atanasyan, rogfer01, MartinMosbeck, brucehoult, the_o, PkmX, jocewei, kristina, jsji, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D54439
</content>
</entry>
<entry>
<title>[APFloat] Fix checked error assert failures</title>
<updated>2020-01-09T07:42:32+00:00</updated>
<author>
<name>Ehud Katz</name>
<email>ehudkatz@gmail.com</email>
</author>
<published>2020-01-09T07:42:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/bcm5719-llvm/commit/?id=24b326cc610dfdccdd50bc78505ec228d96c8e7a'/>
<id>urn:sha1:24b326cc610dfdccdd50bc78505ec228d96c8e7a</id>
<content type='text'>
`APFLoat::convertFromString` returns `Expected` result, which must be
"checked" if the LLVM_ENABLE_ABI_BREAKING_CHECKS preprocessor flag is
set.
To mark an `Expected` result as "checked" we must consume the `Error`
within.
In many cases, we are only interested in knowing if an error occured,
without the need to examine the error info. This is achieved, easily,
with the `errorToBool()` API.
</content>
</entry>
<entry>
<title>[APFloat] Add recoverable string parsing errors to APFloat</title>
<updated>2020-01-06T08:09:01+00:00</updated>
<author>
<name>Ehud Katz</name>
<email>ehudkatz@gmail.com</email>
</author>
<published>2020-01-06T08:05:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/bcm5719-llvm/commit/?id=c5fb73c5d1b3f1adb77d99fc85c594b48bff08f9'/>
<id>urn:sha1:c5fb73c5d1b3f1adb77d99fc85c594b48bff08f9</id>
<content type='text'>
Implementing the APFloat part in PR4745.

Differential Revision: https://reviews.llvm.org/D69770
</content>
</entry>
<entry>
<title>[cmake] Explicitly mark libraries defined in lib/ as "Component Libraries"</title>
<updated>2019-11-21T18:48:08+00:00</updated>
<author>
<name>Tom Stellard</name>
<email>tstellar@redhat.com</email>
</author>
<published>2019-11-14T05:39:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/bcm5719-llvm/commit/?id=ab411801b82783eb7f652701ccfce81b16cf1811'/>
<id>urn:sha1:ab411801b82783eb7f652701ccfce81b16cf1811</id>
<content type='text'>
Summary:
Most libraries are defined in the lib/ directory but there are also a
few libraries defined in tools/ e.g. libLLVM, libLTO.  I'm defining
"Component Libraries" as libraries defined in lib/ that may be included in
libLLVM.so.  Explicitly marking the libraries in lib/ as component
libraries allows us to remove some fragile checks that attempt to
differentiate between lib/ libraries and tools/ libraires:

1. In tools/llvm-shlib, because
llvm_map_components_to_libnames(LIB_NAMES "all") returned a list of
all libraries defined in the whole project, there was custom code
needed to filter out libraries defined in tools/, none of which should
be included in libLLVM.so.  This code assumed that any library
defined as static was from lib/ and everything else should be
excluded.

With this change, llvm_map_components_to_libnames(LIB_NAMES, "all")
only returns libraries that have been added to the LLVM_COMPONENT_LIBS
global cmake property, so this custom filtering logic can be removed.
Doing this also fixes the build with BUILD_SHARED_LIBS=ON
and LLVM_BUILD_LLVM_DYLIB=ON.

2. There was some code in llvm_add_library that assumed that
libraries defined in lib/ would not have LLVM_LINK_COMPONENTS or
ARG_LINK_COMPONENTS set.  This is only true because libraries
defined lib lib/ use LLVMBuild.txt and don't set these values.
This code has been fixed now to check if the library has been
explicitly marked as a component library, which should now make it
easier to remove LLVMBuild at some point in the future.

I have tested this patch on Windows, MacOS and Linux with release builds
and the following combinations of CMake options:

- "" (No options)
- -DLLVM_BUILD_LLVM_DYLIB=ON
- -DLLVM_LINK_LLVM_DYLIB=ON
- -DBUILD_SHARED_LIBS=ON
- -DBUILD_SHARED_LIBS=ON -DLLVM_BUILD_LLVM_DYLIB=ON
- -DBUILD_SHARED_LIBS=ON -DLLVM_LINK_LLVM_DYLIB=ON

Reviewers: beanz, smeenai, compnerd, phosek

Reviewed By: beanz

Subscribers: wuzish, jholewinski, arsenm, dschuff, jyknight, dylanmckay, sdardis, nemanjai, jvesely, nhaehnle, mgorny, mehdi_amini, sbc100, jgravelle-google, hiraditya, aheejin, fedor.sergeev, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, atanasyan, steven_wu, rogfer01, MartinMosbeck, brucehoult, the_o, dexonsmith, PkmX, jocewei, jsji, dang, Jim, lenary, s.egerton, pzheng, sameer.abuasal, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D70179
</content>
</entry>
<entry>
<title>Fix uninitialized variable warning. NFCI</title>
<updated>2019-10-03T11:22:00+00:00</updated>
<author>
<name>Simon Pilgrim</name>
<email>llvm-dev@redking.me.uk</email>
</author>
<published>2019-10-03T11:22:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/bcm5719-llvm/commit/?id=44bc1186e4bdb54f7f15dea8e85d9e83827bd0d0'/>
<id>urn:sha1:44bc1186e4bdb54f7f15dea8e85d9e83827bd0d0</id>
<content type='text'>
llvm-svn: 373583
</content>
</entry>
<entry>
<title>Cosmetic; don't use the magic constant 35 when HASH is more readable. This matches other MCK__&lt;THING&gt;_* usage better.</title>
<updated>2019-09-23T12:52:42+00:00</updated>
<author>
<name>Mark Murray</name>
<email>mark.murray@arm.com</email>
</author>
<published>2019-09-23T12:52:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/bcm5719-llvm/commit/?id=c720f6384535503fb0b1a7da86b462343213837d'/>
<id>urn:sha1:c720f6384535503fb0b1a7da86b462343213837d</id>
<content type='text'>
Summary: No functional change. This fixes a magic constant in MCK__*_... macros only.

Reviewers: ostannard

Subscribers: hiraditya, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D67840

llvm-svn: 372599
</content>
</entry>
<entry>
<title>[llvm] Migrate llvm::make_unique to std::make_unique</title>
<updated>2019-08-15T15:54:37+00:00</updated>
<author>
<name>Jonas Devlieghere</name>
<email>jonas@devlieghere.com</email>
</author>
<published>2019-08-15T15:54:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/bcm5719-llvm/commit/?id=0eaee545eef49ff9498234d3a51a5cbde59bf976'/>
<id>urn:sha1:0eaee545eef49ff9498234d3a51a5cbde59bf976</id>
<content type='text'>
Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
of (hopefully) all the llvm::make_unique instances across the monorepo.

llvm-svn: 369013
</content>
</entry>
<entry>
<title>[AArch64][SVE2] Rename bitperm feature to sve2-bitperm</title>
<updated>2019-07-26T15:57:50+00:00</updated>
<author>
<name>Cullen Rhodes</name>
<email>cullen.rhodes@arm.com</email>
</author>
<published>2019-07-26T15:57:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/bcm5719-llvm/commit/?id=2cde8b5db62c214199ba1b475a925a94d4c78393'/>
<id>urn:sha1:2cde8b5db62c214199ba1b475a925a94d4c78393</id>
<content type='text'>
Summary:
The bitperm feature flag is now prefixed with SVE2, as it is for all other SVE2
extensions

Patch by Maciej Gabka.

Reviewers: sdesmalen, rovka, chill, SjoerdMeijer, rengolin

Reviewed By: SjoerdMeijer, rengolin

Differential Revision: https://reviews.llvm.org/D65327

llvm-svn: 367124
</content>
</entry>
<entry>
<title>MC: AArch64: Add support for prel_g* relocation specifiers.</title>
<updated>2019-07-18T16:54:33+00:00</updated>
<author>
<name>Peter Collingbourne</name>
<email>peter@pcc.me.uk</email>
</author>
<published>2019-07-18T16:54:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/bcm5719-llvm/commit/?id=aa6a7df64a46908baac5b607c658072f96bb3cf8'/>
<id>urn:sha1:aa6a7df64a46908baac5b607c658072f96bb3cf8</id>
<content type='text'>
Differential Revision: https://reviews.llvm.org/D64683

llvm-svn: 366462
</content>
</entry>
<entry>
<title>AArch64: Unify relocation restrictions between MOVK/MOVN/MOVZ.</title>
<updated>2019-07-18T16:51:53+00:00</updated>
<author>
<name>Peter Collingbourne</name>
<email>peter@pcc.me.uk</email>
</author>
<published>2019-07-18T16:51:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/bcm5719-llvm/commit/?id=76427f849fc94ca36e11b0a9d648fa0bba1e22b9'/>
<id>urn:sha1:76427f849fc94ca36e11b0a9d648fa0bba1e22b9</id>
<content type='text'>
There doesn't seem to be a practical reason for these instructions to have
different restrictions on the types of relocations that they may be used
with, notwithstanding the language in the ELF AArch64 spec that implies that
specific relocations are meant to be used with specific instructions.

For example, we currently forbid the first instruction in the following
sequence, despite it currently being used by clang to generate a global
reference under -mcmodel=large:

	movz	x0, #:abs_g0_nc:foo
	movk	x0, #:abs_g1_nc:foo
	movk	x0, #:abs_g2_nc:foo
	movk	x0, #:abs_g3:foo

Therefore, allow MOVK/MOVN/MOVZ to accept the union of the set of relocations
that they currently accept individually.

Differential Revision: https://reviews.llvm.org/D64466

llvm-svn: 366461
</content>
</entry>
</feed>
