| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
Pattern predicates already appear to be emitted as far down as they can be. The optimization was making no changes on any in-tree target.
llvm-svn: 268705
|
|
|
|
|
|
|
| |
DataValueSize is now removed. The change is consolidated
with previous raw version bump.
llvm-svn: 268704
|
|
|
|
|
|
|
| |
DataValueSize is now removed. The change is consolidated
with previous raw version bump.
llvm-svn: 268703
|
|
|
|
| |
llvm-svn: 268702
|
|
|
|
| |
llvm-svn: 268701
|
|
|
|
|
|
|
|
|
|
|
|
| |
If we don't, values that aren't precisely representable in f16 could
be used as-is in a promoted f32 operation, which would produce
incorrect results.
AArch64 had the correct behavior; add a focused test.
Fixes http://llvm.org/PR26871
llvm-svn: 268700
|
|
|
|
| |
llvm-svn: 268699
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change seems to speed up LLD a bit if it has a lot of mergeable
sections. The number is below. It's not too bad for a small patch.
Time to link Clang (debug build):
w/o patch 6.3696 seconds
w/patch 6.2746 seconds (-1.5%)
Differential Revision: http://reviews.llvm.org/D19933
llvm-svn: 268698
|
|
|
|
| |
llvm-svn: 268697
|
|
|
|
|
|
| |
malformedError() in lib/Object/MachOObjectFile.cpp .
llvm-svn: 268696
|
|
|
|
|
|
|
|
| |
This message used to be correct, when all we cared about was whether the
dependence was safe (i.e. NoDep) or unsafe. With the current more
precise characterization, this is a forward dep.
llvm-svn: 268695
|
|
|
|
|
|
| |
No functional change.
llvm-svn: 268694
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a step towards removing the rampant undefined behaviour in
SelectionDAG, which is a part of llvm.org/PR26808.
We rename SelectionDAGISel::Select to SelectImpl and update targets to
match, and then change Select to return void and consolidate the
sketchy behaviour we're trying to get away from there.
Next, we'll update backends to implement `void Select(...)` instead of
SelectImpl and eventually drop the base Select implementation.
llvm-svn: 268693
|
|
|
|
|
|
|
|
|
| |
This opcode never happens in practice, and yet the logic we have in
place to handle it would be undefined behaviour if we ever executed
it. Remove it rather than trying to refactor code that's never
reached.
llvm-svn: 268692
|
|
|
|
|
|
|
|
| |
Patch by Apelete Seketeli.
Differential Revision: http://reviews.llvm.org/D19968
llvm-svn: 268691
|
|
|
|
| |
llvm-svn: 268690
|
|
|
|
|
|
|
|
| |
Use warnings.
Differential revision: reviews.llvm.org/D19946
llvm-svn: 268689
|
|
|
|
|
|
|
| |
This is hopefully last case where we would produce a relocation to a
read only section.
llvm-svn: 268688
|
|
|
|
| |
llvm-svn: 268687
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
"Allow LanguageRuntimes to return an error if they fail in the course of dynamic type discovery
This is not meant to report that a value doesn't have a dynamic type - it is only meant as a mechanism to propagate actual type discovery issues (e.g. malformed type metadata for languages that have such a notion)
This information is used by ValueObjectDynamic to set its own m_error, which is a fairly sharp and heavyweight tool to begin with
For the time being, this is an architectural improvement but a practical no-op as no existing runtimes are actually setting errors"
I need to think about what I want to do in this space more carefully - this attempt might be too heavy of a hammer for the nail I am trying to fix, and I don't want to leave it in while I ponder
llvm-svn: 268686
|
|
|
|
|
|
| |
Since the option was removed in r268670, the cache scripts should stop referring to it.
llvm-svn: 268685
|
|
|
|
| |
llvm-svn: 268684
|
|
|
|
|
|
|
| |
This FIXME was already fixed, and these LF_* enum names were
inconsistent.
llvm-svn: 268683
|
|
|
|
| |
llvm-svn: 268682
|
|
|
|
| |
llvm-svn: 268681
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit r268658.
I incorrectly diagnose this as the source of an assertion during an
LTO bootstrap of clang.
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 268680
|
|
|
|
| |
llvm-svn: 268679
|
|
|
|
| |
llvm-svn: 268678
|
|
|
|
| |
llvm-svn: 268677
|
|
|
|
| |
llvm-svn: 268676
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: We need to clean up CFG before assigning discriminator to minimize the impact of optimization on debug info.
Reviewers: davidxl, dblaikie, dnovillo
Subscribers: dnovillo, danielcdh, llvm-commits
Differential Revision: http://reviews.llvm.org/D19926
llvm-svn: 268675
|
|
|
|
|
|
|
|
| |
Use warnings.
Differential revision: http://reviews.llvm.org/D19947
llvm-svn: 268674
|
|
|
|
|
|
|
|
| |
This fixes http://llvm.org/PR27646 on Mips64.
Differential Revision: http://reviews.llvm.org/D19989
llvm-svn: 268673
|
|
|
|
| |
llvm-svn: 268672
|
|
|
|
|
|
|
|
|
|
| |
The assertions were assuming that the linker will not ask to preserve
a global that is internal or available_externally, as it does not
really make sense. In practice this break the bootstrap of clang,
I degrade to a warning for now.
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 268671
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
As per the discussion on LLVM-dev this patch proposes removing LLVM_ENABLE_TIMESTAMPS.
The only complicated bit of this patch is the Windows support. On windows we used to log an error if /INCREMENTAL was passed to the linker when timestamps were disabled.
With this change since timestamps in code are always disabled we will always compile on windows with /Brepro unless /INCREMENTAL is specified, and we will log a warning when /INCREMENTAL is specified to notify the user that the build will be non-deterministic.
See: http://lists.llvm.org/pipermail/llvm-dev/2016-May/098990.html
Reviewers: bogner, silvas, rnk
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D19892
llvm-svn: 268670
|
|
|
|
|
|
| |
Thanks to David Li for the clarification.
llvm-svn: 268669
|
|
|
|
|
|
|
|
| |
We were creating the copy relocations just fine, but then thinking that
the .bss position could be preempted and creating a dynamic relocation
to it, which would crash at runtime since that memory is read only.
llvm-svn: 268668
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D19956
llvm-svn: 268667
|
|
|
|
|
|
|
| |
complains of missing HexagonAlias.td on ninja.
FIXME: TableGen.cmake globs *.td(s) with wildcards for deps. It is not good.
llvm-svn: 268666
|
|
|
|
| |
llvm-svn: 268665
|
|
|
|
|
|
| |
using-declaration that names a class-scope enumerator.
llvm-svn: 268664
|
|
|
|
| |
llvm-svn: 268663
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Given something like:
ldr r0, .LCPI0_0 (== pc-rel var)
add r0, pc
ldr r1, .LCPI0_1 (== pc-rel var)
add r1, pc
we cannot combine the 2 ldr instructions and litpools because they get added to
a different pc to form the correct address. I think the original logic came
from a time when we fused the LDRpci/PICADD instructions into one
pseudo-instruction so the PC was always immediately at-hand. That's no longer
the case.
Should fix general-dynamic TLS access on Linux, and quite possibly other -fPIC
code that relies on litpools (e.g. v6m and -Oz compilations) though trivial
tweaks of the .ll test didn't provoke anything.
llvm-svn: 268662
|
|
|
|
|
|
| |
The mem(r0) instructions are treated as mem(r0+#0).
llvm-svn: 268661
|
|
|
|
|
|
|
|
|
| |
MemorySanitizer: use-of-uninitialized-value in lib/Bitcode/Writer/BitcodeWriter.cpp:364:70
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/12544/steps/check-llvm%20msan/logs/stdio
This reverts commit 0c4a898ea550699d1b2f4fe3767251c8f9a48d52.
llvm-svn: 268660
|
|
|
|
| |
llvm-svn: 268659
|
|
|
|
|
|
|
| |
This should fix the assertions in a clang LTO bootstrap we're seeing.
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 268658
|
|
|
|
| |
llvm-svn: 268657
|
|
|
|
| |
llvm-svn: 268656
|