| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
| |
an inverted compare. NFC
Do the same for (X | (Y & ~X)) -> (X | Y)
llvm-svn: 308104
|
| |
|
|
|
|
| |
merge them into a existing test file. NFC
llvm-svn: 308103
|
| |
|
|
|
|
|
|
|
| |
This fold hit the trifecta:
1. It was untested.
2. It oversteps (multiuse is not checked, so increases instruction count).
3. It is incomplete (doesn't work for vectors).
llvm-svn: 308102
|
| |
|
|
| |
llvm-svn: 308101
|
| |
|
|
|
|
| |
to the newly improved AA information.
llvm-svn: 308100
|
| |
|
|
| |
llvm-svn: 308099
|
| |
|
|
| |
llvm-svn: 308098
|
| |
|
|
| |
llvm-svn: 308097
|
| |
|
|
|
|
|
| |
These patterns and tests were added to InstSimplify with:
https://reviews.llvm.org/rL303004
llvm-svn: 308096
|
| |
|
|
|
|
|
|
|
| |
that appears to exhibit non-determinism and is flaking on the bots
pretty consistently.
r308078: [ThinLTO] Ensure we always select the same function copy to import
r308079: Require asserts in new test that uses debug flag
llvm-svn: 308095
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: anemet, karthikthecool, blitz.opensource
Reviewed By: anemet
Subscribers: mzolotukhin, llvm-commits
Differential Revision: https://reviews.llvm.org/D35122
llvm-svn: 308094
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: grosser, Meinersbur, bollu
Subscribers: pollydev
Tags: #polly
Contributed-by: Nandini Singhal <cs15mtech01004@iith.ac.in>
Differential Revision: https://reviews.llvm.org/D35453
llvm-svn: 308093
|
| |
|
|
|
|
|
|
| |
be shared without warnings. Build AttributedTypes to leave breadcrumbs
for tools like the static analyzer. Warn about attempting to use the
attribute with incompatible return types.
llvm-svn: 308092
|
| |
|
|
|
|
|
|
| |
Summary: Maybe I mismerged when merging previous commits by hand.
Differential Revision: https://reviews.llvm.org/D35448
llvm-svn: 308091
|
| |
|
|
|
|
|
|
|
| |
objects to start at the same address
As discussed on the ML, there's consensus that this is what the implementations
do and it seems sensible.
llvm-svn: 308090
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: grosser, Meinersbur, bollu
Subscribers: maxf, pollydev
Tags: #polly
Contributed-by: Nandini Singhal <cs15mtech01004@iith.ac.in>
Differential Revision: https://reviews.llvm.org/D35308
llvm-svn: 308089
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
function to every defined function known to LLVM as a library function.
LLVM can introduce calls to these functions either by replacing other
library calls or by recognizing patterns (such as memset_pattern or
vector math patterns) and replacing those with calls. When these library
functions are actually defined in the module, we need to have reference
edges to them initially so that we visit them during the CGSCC walk in
the right order and can effectively rebuild the call graph afterward.
This was discovered when building code with Fortify enabled as that is
a common case of both inline definitions of library calls and
simplifications of code into calling them.
This can in extreme cases of LTO-ing with libc introduce *many* more
reference edges. I discussed a bunch of different options with folks but
all of them are unsatisfying. They either make the graph operations
substantially more complex even when there are *no* defined libfuncs, or
they introduce some other complexity into the callgraph. So this patch
goes with the simplest possible solution of actual synthetic reference
edges. If this proves to be a memory problem, I'm happy to implement one
of the clever techniques to save memory here.
llvm-svn: 308088
|
| |
|
|
|
|
|
|
|
|
| |
If the `long-calls` feature flags is enabled, disable use of the `jal`
instruction. Instead of that call a function by by first loading its
address into a register, and then using the contents of that register.
Differential revision: https://reviews.llvm.org/D35168
llvm-svn: 308087
|
| |
|
|
| |
llvm-svn: 308086
|
| |
|
|
|
|
| |
r308015 introduced clangBasic to instantiate Diagnostics &c,
llvm-svn: 308085
|
| |
|
|
| |
llvm-svn: 308084
|
| |
|
|
|
| |
Signed-off-by: Yonghong Song <yhs@fb.com>
llvm-svn: 308083
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The type needs to be casted back to the original argument type.
Fixes an assert that for some reason is only run when
using -debug.
Includes an additional combine to avoid test regressions
from having conversions mixed with multiple Assert[SZ]ext
nodes. On subtargets where i16 is legal, this was producing an i32
register with an i16 AssertZExt, truncated to i16 with another i8
AssertZExt.
t2: i32,ch = CopyFromReg t0, Register:i32 %vreg0
t3: i16 = truncate t2
t5: i16 = AssertZext t3, ValueType:ch:i8
t6: i8 = truncate t5
t7: i32 = zero_extend t6
llvm-svn: 308082
|
| |
|
|
| |
llvm-svn: 308081
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, for code like below,
===
inner_map = bpf_map_lookup_elem(outer_map, &port_key);
if (!inner_map) {
inner_map = &fallback_map;
}
===
the compiler generates (pseudo) code like the below:
===
I1: r1 = bpf_map_lookup_elem(outer_map, &port_key);
I2: r2 = 0
I3: if (r1 == r2)
I4: r6 = &fallback_map
I5: ...
===
During kernel verification process, After I1, r1 holds a state
map_ptr_or_null. If I3 condition is not taken
(path [I1, I2, I3, I5]), supposedly r1 should become map_ptr.
Unfortunately, kernel does not recognize this pattern
and r1 remains map_ptr_or_null at insn I5. This will cause
verificaiton failure later on.
Kernel, however, is able to recognize pattern "if (r1 == 0)"
properly and give a map_ptr state to r1 in the above case.
LLVM here generates suboptimal code which causes kernel verification
failure. This patch fixes the issue by changing BPF insn pattern
matching and lowering to generate proper codes if the righthand
parameter of the above condition is a constant. A test case
is also added.
Signed-off-by: Yonghong Song <yhs@fb.com>
llvm-svn: 308080
|
| |
|
|
|
|
| |
This should fix bot failures from r308078.
llvm-svn: 308079
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Check if the first eligible callee is under the instruction threshold.
Checking this on the first eligible callee ensures that we don't end
up selecting different callees to import when we invoke this routine
with different thresholds due to reaching the callee via paths that
are shallower or hotter (when there are multiple copies, i.e. with
weak or linkonce linkage). We don't want to leave the decision of which
copy to import up to the backend.
Reviewers: mehdi_amini
Subscribers: inglorion, fhahn, llvm-commits
Differential Revision: https://reviews.llvm.org/D35436
llvm-svn: 308078
|
| |
|
|
|
|
|
| |
Reapply r307720 to allow processing of constructors and destructors. Reuse
the diagnostics for CXXMethodDecl for them.
llvm-svn: 308077
|
| |
|
|
|
|
|
|
|
|
|
| |
Now, getUserCost() only checks the src and dst types of EXT to decide it is free
or not. This change first checks the types, then calls isExtFreeImpl(), and
check if EXT can form ExtLoad at last. Currently, only AArch64 has customized
implementation of isExtFreeImpl() to check if EXT can be folded into its use.
Differential Revision: https://reviews.llvm.org/D34458
llvm-svn: 308076
|
| |
|
|
| |
llvm-svn: 308075
|
| |
|
|
|
|
|
|
| |
This fixes a minor bug in insertion to a reachable node that caused
DominatorTree.InsertDeleteExhaustive flakiness. The patch also adds
a new testcase for this exact failure.
llvm-svn: 308074
|
| |
|
|
|
|
|
|
|
| |
This diff makes the test FixIt/format.m more robust.
The issue was caught by the build bot clang-cmake-thumbv7-a15.
Test plan: make check-all
llvm-svn: 308073
|
| |
|
|
|
|
|
|
| |
says so
Differential Revision: https://reviews.llvm.org/D35400
llvm-svn: 308072
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Module builds somehow report an ambiguity between clang::Diagnostic and
clang::Tooling::Diagnostic. It seems as if one of the additional headers
brought in by the module brings the clang namespace to the toplevel. I
could not find out the reason for that, so for now I go with the simple
fix to bring the build back to green.
rdar://33321397
llvm-svn: 308071
|
| |
|
|
|
|
|
|
| |
The DominatorTree.InsertDeleteExhaustive uses a RNG with a
constant seed to generate different sequences of updates. The test
fails on some buildbots and this patch disables it for now.
llvm-svn: 308070
|
| |
|
|
|
|
|
|
|
|
|
| |
With this change, libFuzzer will ignore any arguments after a sigil
argument, but it will preserve these arguments at the end of the
command line when launching subprocesses. Using this, its possible to
handle positional and single-dash arguments to the program under test
by discarding everything up to -ignore_remaining_args=1 in
LLVMFuzzerInitialize.
llvm-svn: 308069
|
| |
|
|
| |
llvm-svn: 308068
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This diff addresses FIXME in lib/Analysis/PrintfFormatString.cpp
and makes PrintfSpecifier::getArgType return the correct type.
In particular, this change enables Clang to emit a warning on
incorrect using of "%zd"/"%zn" format specifiers.
Differential revision: https://reviews.llvm.org/D35427
Test plan: make check-all
llvm-svn: 308067
|
| |
|
|
|
|
| |
This code runs after clearOutputSections.
llvm-svn: 308066
|
| |
|
|
| |
llvm-svn: 308065
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Set proper errno code on alloction failures and change some
implementations to satisfy their man-specified requirements:
LSan: valloc and memalign
ASan: pvalloc, memalign and posix_memalign
Changing both allocators in one patch since LSan depends on ASan allocator in some configurations.
Reviewers: vitalybuka
Subscribers: kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D35440
llvm-svn: 308064
|
| |
|
|
|
|
|
| |
Set proper errno code on alloction failures and change valloc and
memalign implementations to satisfy their man-specified requirements.
llvm-svn: 308063
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch implements incremental edge deletions.
It also makes DominatorTreeBase store a pointer to the parent function. The parent function is needed to perform full rebuilts during some deletions, but it is also used to verify that inserted and deleted edges come from the same function.
Reviewers: dberlin, davide, grosser, sanjoy, brzycki
Reviewed By: dberlin
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D35342
llvm-svn: 308062
|
| |
|
|
| |
llvm-svn: 308061
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Restricting register class to PointerRegClass for memory operands.
Also fix the PointerRegClass for AArch64 from GPR64 to GPR64sp, since
XZR cannot hold a memory pointer while SP is.
Fixes PR33134.
Differential Revision: https://reviews.llvm.org/D34999
llvm-svn: 308060
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch is the first step in reducing HW prefetcher instruction tag
collisions in inner loops for Falkor. It adds a pass that annotates IR
loads with metadata to indicate that they are known to be strided loads,
and adds a target lowering hook that translates this metadata to a
target-specific MachineMemOperand flag.
A follow on change will use this MachineMemOperand flag to re-write
instructions to reduce tag collisions.
Reviewers: mcrosier, t.p.northover
Subscribers: aemerson, rengolin, mgorny, javed.absar, kristof.beyls, llvm-commits
Differential Revision: https://reviews.llvm.org/D34963
llvm-svn: 308059
|
| |
|
|
| |
llvm-svn: 308058
|
| |
|
|
| |
llvm-svn: 308057
|
| |
|
|
|
|
| |
NFC, just makes the OutputSectionCommand available.
llvm-svn: 308056
|
| |
|
|
| |
llvm-svn: 308055
|