lp:~vcs-imports/llvm/llvm-trunk

Created by Jelmer Vernooij on 2011-06-07 and last modified on 2018-01-22
Get this branch:
bzr branch lp:~vcs-imports/llvm/llvm-trunk

Branch merges

Related bugs

Related blueprints

Branch information

Owner:
VCS imports
Project:
LLVM
Status:
Development

Import details

Import Status: Reviewed

This branch is an import of the Subversion branch from http://llvm.org/svn/llvm-project/llvm/trunk.

The next import is scheduled to run in 5 hours.

Last successful import was 46 minutes ago.

Import started 48 minutes ago on pear and finished 46 minutes ago taking 1 minute — see the log
Import started 6 hours ago on pear and finished 6 hours ago taking 1 minute — see the log
Import started 12 hours ago on russkaya and finished 12 hours ago taking 2 minutes — see the log
Import started 18 hours ago on pear and finished 18 hours ago taking 1 minute — see the log
Import started on 2018-01-21 on pear and finished on 2018-01-21 taking 50 seconds — see the log
Import started on 2018-01-20 on pear and finished on 2018-01-20 taking 1 minute — see the log
Import started on 2018-01-20 on pear and finished on 2018-01-20 taking 1 minute — see the log
Import started on 2018-01-20 on pear and finished on 2018-01-20 taking 1 minute — see the log
Import started on 2018-01-20 on pear and finished on 2018-01-20 taking 1 minute — see the log
Import started on 2018-01-19 on pear and finished on 2018-01-19 taking 1 minute — see the log

Recent revisions

159383. By lhames 3 hours ago

[ORC] Add orc::SymbolResolver, a Orc/Legacy API interop header, and an
orc::SymbolResolver to JITSymbolResolver adapter.

The new orc::SymbolResolver interface uses asynchronous queries for better
performance. (Asynchronous queries with bulk lookup minimize RPC/IPC overhead,
support parallel incoming queries, and expose more available work for
distribution). Existing ORC layers will soon be updated to use the
orc::SymbolResolver API rather than the legacy llvm::JITSymbolResolver API.

Because RuntimeDyld still uses JITSymbolResolver, this patch also includes an
adapter that wraps an orc::SymbolResolver with a JITSymbolResolver API.

159382. By spatel 14 hours ago

[InstCombine] (X << Y) / X -> 1 << Y

...when the shift is known to not overflow with the matching
signed-ness of the division.

This closes an optimization gap caused by canonicalizing mul
by power-of-2 to shl as shown in PR35709:
https://bugs.llvm.org/show_bug.cgi?id=35709

Patch by Anton Bikineev!

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

159381. By spatel 14 hours ago

[InstSimplify] add baseline tests for (X << Y) % X -> 0; NFC

This is the 'rem' counterpart to D42032 and would be folded by
D42341.

Patch by Anton Bikineev.

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

159380. By evgeny777 19 hours ago

Temporarily revert r323062 to investigate buildbot failures

159379. By evgeny777 21 hours ago

An attempt to fix buildbot after rL323062

159378. By evgeny777 22 hours ago

[ThinLTO] Implement summary visualizer

Differential revision: https://reviews.llvm.org/D41297

159377. By lhames on 2018-01-21

[ORC] Add a lookupFlags method to VSO.

lookupFlags returns a SymbolFlagsMap for the requested symbols, along with a
set containing the SymbolStringPtr for any symbol not found in the VSO.

The JITSymbolFlags for each symbol will have been stripped of its transient
JIT-state flags (i.e. NotMaterialized, Materializing).

Calling lookupFlags does not trigger symbol materialization.

159376. By lhames on 2018-01-21

[ORC] More cleanup. NFC.

159375. By kuhar on 2018-01-21

[Dominators] Remove misleading double-deletion test

Summary:
It's generally not safe to perform multiple DomTree updates without using the incremental API.

Although it is supposed to work in this particular case, the testcase is misleading/confusing, and it's better to remove it.

Reviewers: dberlin, brzycki, davide, grosser

Reviewed By: davide

Subscribers: llvm-commits

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

159374. By lhames on 2018-01-21

[ORC] Cleanup. NFC.

Branch metadata

Branch format:
Branch format 7
Repository format:
Bazaar repository format 2a (needs bzr 1.16 or later)
This branch contains Public information 
Everyone can see this information.

Subscribers