| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 244927
|
| |
|
|
| |
llvm-svn: 244926
|
| |
|
|
| |
llvm-svn: 244925
|
| |
|
|
| |
llvm-svn: 244924
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
files: include the .pcm file itself in the .d output, rather than including its
own input files. Other forms of module file continue to be transparent for .d
output.
Arguably, the input files for the .pcm file are still inputs to the
compilation, but that's unnecessary for make-like build systems (where the
mtime of the .pcm file is sufficient) and harmful for smarter build systems
that know about module files and want to track only the local dependencies.
llvm-svn: 244923
|
| |
|
|
|
|
|
|
|
|
|
| |
-fno-rtti-data makes it so that vtables emitted in the current TU lack
RTTI data. This means that dynamic_cast usually fails at runtime. Users
of the existing cxx_rtti feature expect all of RTTI to work, not just
some of it.
Chromium bug for context: http://crbug.com/518191
llvm-svn: 244922
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This patch corresponds to review:
http://reviews.llvm.org/D11471
It improves the code generated for converting a scalar to a vector value. With
direct moves from GPRs to VSRs, we no longer require expensive stack operations
for this. Subsequent patches will handle the reverse case and more general
operations between vectors and their scalar elements.
llvm-svn: 244921
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D11352
llvm-svn: 244920
|
| |
|
|
| |
llvm-svn: 244919
|
| |
|
|
|
|
| |
This will allow further cleanups.
llvm-svn: 244918
|
| |
|
|
|
|
|
| |
Some compilers were less happy about converting a lambda to a comparator
function for array_pod_sort.
llvm-svn: 244917
|
| |
|
|
|
|
|
|
| |
This was my error. We've got f32 marked as legal because they're simulated using a v2f32 instruction, but there's no equivalent for f64.
This will get test coverage imminently when D12015 lands.
llvm-svn: 244916
|
| |
|
|
|
|
|
|
| |
This overrides the default to more closely resemble the hand-crafted matching logic in ISelLowering. It makes sense, as there is no VFP equivalent of vmin or vmax, to use them when they're available even if in general VFP ops should be preferred.
This should be NFC.
llvm-svn: 244915
|
| |
|
|
|
|
| |
They rely on global fast-math options, but soon ISel will rely only on fast-math flags on the instructions themselves. Rip the fast checks out into their own file so we can mark their instructions as fast.
llvm-svn: 244914
|
| |
|
|
|
|
|
|
|
| |
These tests relied on -enable-no-nans-fp-math, whereas soon they'll take their no-nans hint
from the FCMP instruction itself, so split the no-nans stuff out into its own test.
Also do a slight rejig of instruction order. The old FMIN/MAX backend matching had to deal with looking through casts, which it never did particularly well. Now, instcombine will recognize such patterns and canonicalize the cast outside the select. So modify the test inputs to assume that instcombine has already run.
llvm-svn: 244913
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This preserves backwards compatibility for two hacks in the Darwin
system module map files:
1. The use of 'requires excluded' to make headers non-modular, which
should really be mapped to 'textual' now that we have this feature.
2. Silently removes a bogus cplusplus requirement from IOKit.avc.
Once we start diagnosing missing requirements and headers on
auto-imports these would have broken compatibility with existing Darwin
SDKs.
llvm-svn: 244912
|
| |
|
|
|
|
| |
This is mandated by the ELF spec.
llvm-svn: 244911
|
| |
|
|
|
|
|
| |
I forgot to audit lib/sanitizer_common for the same issue. This fixes
writing out coverage files on exit.
llvm-svn: 244910
|
| |
|
|
|
|
|
| |
Apparently /Zc:inline causes static globals in custom sections to be
discarded if they are unreferenced.
llvm-svn: 244908
|
| |
|
|
| |
llvm-svn: 244907
|
| |
|
|
| |
llvm-svn: 244906
|
| |
|
|
|
|
| |
That is the value that is stable as the we layout the output sections.
llvm-svn: 244904
|
| |
|
|
|
|
|
| |
CodeGenerator currently tries to generate code for a parameter using
values values that are computed later.
llvm-svn: 244903
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
When we want to use mingw-w64 and clang with compiler-rt we should not
need to have libgcc installed. This fixes finding includes when libgcc
is not installed
Reviewers: yaron.keren
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D11808
llvm-svn: 244902
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
different block.
DeadStoreElimination does eliminate a store if it stores a value which was loaded from the same memory location.
So far this worked only if the store is in the same block as the load.
Now we can also handle stores which are in a different block than the load.
Example:
define i32 @test(i1, i32*) {
entry:
%l2 = load i32, i32* %1, align 4
br i1 %0, label %bb1, label %bb2
bb1:
br label %bb3
bb2:
; This store is redundant
store i32 %l2, i32* %1, align 4
br label %bb3
bb3:
ret i32 0
}
Differential Revision: http://reviews.llvm.org/D11854
llvm-svn: 244901
|
| |
|
|
| |
llvm-svn: 244900
|
| |
|
|
|
|
|
| |
This macro and the small amount of code along with it are unused and
can be removed. The macro is never defined in any build script or source file.
llvm-svn: 244899
|
| |
|
|
|
|
| |
Having them in the middle of the file complicates the creation of segments.
llvm-svn: 244898
|
| |
|
|
|
|
|
|
|
|
|
| |
Previously, for O32 ABI we did not calculate correct addend for R_MIPS_HI16
and R_MIPS_PCHI16 relocations. This patch fixes that.
Patch by Vladimir Radosavljevic.
Differential Revision: http://reviews.llvm.org/D11186
llvm-svn: 244897
|
| |
|
|
| |
llvm-svn: 244896
|
| |
|
|
| |
llvm-svn: 244895
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Update the demotion logic in WinEHPrepare to avoid creating new cleanups by
walking predecessors as necessary to insert stores for EH-pad PHIs.
Also avoid creating stores for EH-pad PHIs that have no uses.
The store/load placement is still pretty naive. Likely future improvements
(at least for optimized compiles) include:
- Share loads for related uses as possible
- Coalesce non-interfering use/def-related PHIs
- Store at definition point rather than each PHI pred for non-interfering
lifetimes.
Reviewers: rnk, majnemer
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D11955
llvm-svn: 244894
|
| |
|
|
|
|
|
|
|
|
| |
Use the canonical __aarch64__ predefined macro for 64-bit ARM. Apple-
specific cases are left as __arm64__. Also add an #error for unsupported
architectures to catch this sort of case in the future.
Differential Revision: http://reviews.llvm.org/D12005
llvm-svn: 244893
|
| |
|
|
|
|
|
| |
I encountered this on FreeBSD/arm64, and then found the same issue was
reported by Daniil Troshkov.
llvm-svn: 244892
|
| |
|
|
|
|
|
|
|
|
| |
Before:
decltype(a* b) F();
After:
decltype(a * b) F();
llvm-svn: 244891
|
| |
|
|
|
|
|
|
|
|
| |
Before:
[ a, a ]() -> a<1>{};
After:
[a, a]() -> a<1> {};
llvm-svn: 244890
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Recent mesa/llvmpipe crashes on SystemZ due to a failed assertion when
attempting to compile a routine with a return type of
{ <4 x float>, <4 x float>, <4 x float>, <4 x float> }
on a system without vector instruction support.
This is because after legalizing the vector type, we get a return value
consisting of 16 floats, which cannot all be returned in registers.
Usually, what should happen in this case is that the target's CanLowerReturn
routine rejects the return type, in which case SelectionDAG falls back to
implementing a structure return in memory via implicit reference.
However, the SystemZ target never actually implemented any CanLowerReturn
routine, and thus would accept any struct return type.
This patch fixes the crash by implementing CanLowerReturn. As a side effect,
this also handles fp128 return values, fixing a todo that was noted in
SystemZCallingConv.td.
llvm-svn: 244889
|
| |
|
|
| |
llvm-svn: 244888
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Consider this code:
BB:
%i = phi i32 [ 0, %if.then ], [ %c, %if.else ]
%add = add nsw i32 %i, %b
...
In this common case the add can be moved to the %if.else basic block, because
adding zero is an identity operation. If we go though %if.then branch it's
always a win, because add is not executed; if not, the number of instructions
stays the same.
This pattern applies also to other instructions like sub, shl, shr, ashr | 0,
mul, sdiv, div | 1.
Patch by Jakub Kuderski!
llvm-svn: 244887
|
| |
|
|
| |
llvm-svn: 244886
|
| |
|
|
|
|
|
| |
This reverts commit r244879, as it broke the test-suite on
SingleSource/Regression/C/2004-03-15-IndirectGoto in AArch64.
llvm-svn: 244885
|
| |
|
|
|
|
|
|
|
| |
analysis in LoopIdiomRecognize."
This reverts commit r244880, as it broke the test-suite on
SingleSource/Regression/C/2004-03-15-IndirectGoto in AArch64.
llvm-svn: 244884
|
| |
|
|
| |
llvm-svn: 244883
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Other than PC-relative loads/store the patterns that match the various
load/store addressing modes have the same complexity, so the order that they
are matched is the order that they appear in the .td file.
Rearrange the instruction definitions in ARMInstrThumb.td, and make use of
AddedComplexity for PC-relative loads, so that the instruction matching order
is the order that results in the simplest selection logic. This also makes
register-offset load/store be selected when it should, as previously it was
only selected for too-large immediate offsets.
Differential Revision: http://reviews.llvm.org/D11800
llvm-svn: 244882
|
| |
|
|
| |
llvm-svn: 244881
|
| |
|
|
|
|
|
| |
in LoopIdiomRecognize. This is what started me staring at this code. Now
migrating it with the new AA stuff will be trivial.
llvm-svn: 244880
|
| |
|
|
|
|
|
|
|
|
|
| |
simplified form to remove redundant checks and simplify the code for
popcount recognition. We don't actually need to handle all of these
cases.
I've left a FIXME for one in particular until I finish inspecting to
make sure we don't actually *rely* on the predicate in any way.
llvm-svn: 244879
|
| |
|
|
|
|
| |
really in breaking pattern just for this analysis.
llvm-svn: 244878
|
| |
|
|
| |
llvm-svn: 244877
|
| |
|
|
| |
llvm-svn: 244876
|