| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 212194
|
| |
|
|
|
|
|
| |
Temporarily disable AArch64AddressTypePromotion, which was effectively
re-enabled in r212073 and r212075, while I look into PR20188.
llvm-svn: 212189
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
See https://code.google.com/p/address-sanitizer/issues/detail?id=299 for the
original feature request.
Introduce llvm.asan.globals metadata, which Clang (or any other frontend)
may use to report extra information about global variables to ASan
instrumentation pass in the backend. This metadata replaces
llvm.asan.dynamically_initialized_globals that was used to detect init-order
bugs. llvm.asan.globals contains the following data for each global:
1) source location (file/line/column info);
2) whether it is dynamically initialized;
3) whether it is blacklisted (shouldn't be instrumented).
Source location data is then emitted in the binary and can be picked up
by ASan runtime in case it needs to print error report involving some global.
For example:
0x... is located 4 bytes to the right of global variable 'C::array' defined in '/path/to/file:17:8' (0x...) of size 40
These source locations are printed even if the binary doesn't have any
debug info.
This is an ABI-breaking change. ASan initialization is renamed to
__asan_init_v4(). Pre-built libraries compiled with older Clang will not work
with the fresh runtime.
llvm-svn: 212188
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit r212109, which reverted r212088.
However, disable the assert as it's not necessary for correctness. There are
several corner cases that the assert needed to handle better for in-order
scheduling, but none of them are incorrect scheduler behavior. The assert is
mainly there to collect good unit tests like this and ensure that the
target-independent scheduler is working as expected with the various machine
models.
llvm-svn: 212187
|
| |
|
|
|
|
|
| |
CombineTo doesn't allow replacing a node with itself so this would crash if the
combined shuffle is the same as the input shuffle.
llvm-svn: 212181
|
| |
|
|
|
|
|
| |
After Alexey Volkov, I'm adding the same property for KNL, that prefers ADD/SUB instead of INC/DEC.
Added a test.
llvm-svn: 212178
|
| |
|
|
| |
llvm-svn: 212168
|
| |
|
|
|
|
|
| |
The result of x/INT_MIN is either 0 or 1, we can just use an icmp
instead.
llvm-svn: 212167
|
| |
|
|
|
|
|
| |
switches) into a switch, and sink them into a dispatch function that can
return the result rather than awkward variable setting with breaks.
llvm-svn: 212166
|
| |
|
|
|
|
|
|
|
| |
It is not safe to negate the smallest signed integer, doing so yields
the same number back.
This fixes PR20186.
llvm-svn: 212164
|
| |
|
|
|
|
|
|
|
|
| |
Based on the support for .req on ARM. The aarch64 variant has to keep track if
the alias register was a vector register (v0-31) or a general purpose or
VFP/Advanced SIMD ([bhsdq]0-31) register.
Patch by Janne Grunau!
llvm-svn: 212161
|
| |
|
|
|
|
|
|
| |
r212158 but missed.
Thanks to Craig for spotting the goof!
llvm-svn: 212159
|
| |
|
|
|
|
|
| |
so that we can use return to express it more cleanly and avoid so many
nested switch statements.
llvm-svn: 212158
|
| |
|
|
|
|
|
| |
This doesn't add any information for methods in the VectorLegalizer
class that clearly take SDAG operations to legalize.
llvm-svn: 212157
|
| |
|
|
|
|
| |
operation legalization code.
llvm-svn: 212155
|
| |
|
|
|
|
| |
a separate function and clean up calling convention for helper function.
llvm-svn: 212153
|
| |
|
|
| |
llvm-svn: 212152
|
| |
|
|
| |
llvm-svn: 212151
|
| |
|
|
| |
llvm-svn: 212150
|
| |
|
|
| |
llvm-svn: 212149
|
| |
|
|
|
|
| |
down to the subtarget.
llvm-svn: 212147
|
| |
|
|
|
|
| |
that information.
llvm-svn: 212146
|
| |
|
|
|
|
| |
helper method. NFCI.
llvm-svn: 212140
|
| |
|
|
|
|
|
|
|
| |
Otherwise they get freed and the implicit "isa<XYZ>" tests following
turn out badly (at least under sanitizers).
Also corrects the ordering of unordered atomic stores.
llvm-svn: 212136
|
| |
|
|
|
|
|
|
| |
The argument list vector is never used after it has been passed to the
CallLoweringInfo and moving it to the CallLoweringInfo is cleaner and
pretty much as cheap as keeping a pointer to it.
llvm-svn: 212135
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On targets without cmpxchg16b or cmpxchg8b, the borderline atomic
operations were slipping through the gaps.
X86AtomicExpand.cpp was delegating to ISelLowering. Generic
ISelLowering was delegating to X86ISelLowering and X86ISelLowering was
asserting. The correct behaviour is to expand to a libcall, preferably
in generic ISelLowering.
This can be achieved by X86ISelLowering deciding it doesn't want the
faff after all.
llvm-svn: 212134
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch reduces the stack memory consumption of the InstCombine
function "isOnlyCopiedFromConstantGlobal() ", that in certain conditions
could overflow the stack because of excessive recursiveness.
For example, in a case like this:
%0 = alloca [50025 x i32], align 4
%1 = getelementptr inbounds [50025 x i32]* %0, i64 0, i64 0
store i32 0, i32* %1
%2 = getelementptr inbounds i32* %1, i64 1
store i32 1, i32* %2
%3 = getelementptr inbounds i32* %2, i64 1
store i32 2, i32* %3
%4 = getelementptr inbounds i32* %3, i64 1
store i32 3, i32* %4
%5 = getelementptr inbounds i32* %4, i64 1
store i32 4, i32* %5
%6 = getelementptr inbounds i32* %5, i64 1
store i32 5, i32* %6
...
This piece of code crashes llvm when trying to apply instcombine on
desktop. On embedded devices this could happen with a much lower limit
of recursiveness. Some instructions (getelementptr and bitcasts) make
the function recursively call itself on their uses, which is what makes
the example above consume so much stack (it becomes a recursive
depth-first tree visit with a very big depth).
The patch changes the algorithm to be semantically equivalent, but
iterative instead of recursive and the visiting order to be from a
depth-first visit to a breadth-first visit (visit all the instructions
of the current level before the ones of the next one).
Now if a lot of memory is required a heap allocation is done instead of
the the stack allocation, avoiding the possible crash.
Reviewed By: rnk
Differential Revision: http://reviews.llvm.org/D4355
Patch by Marcello Maggioni! We don't generally commit large stress test
that look for out of memory conditions, so I didn't request that one be
added to the patch.
llvm-svn: 212133
|
| |
|
|
|
|
|
|
|
| |
This macro is sometimes defined manually but isn't (and doesn't need to be) in
llvm-config.h so shouldn't appear in the headers, likewise NDEBUG.
Instead switch them over to LLVM_DUMP_METHOD on the definitions.
llvm-svn: 212130
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Matching behavior with DeadArgumentElimination (and leveraging some
now-common infrastructure), keep track of the function from debug info
metadata if arguments are promoted.
This may produce interesting debug info - since the arguments may be
missing or of different types... but at least backtraces, inlining, etc,
will be correct.
llvm-svn: 212128
|
| |
|
|
|
|
| |
down to the subtarget. Add an initialization routine to assist.
llvm-svn: 212124
|
| |
|
|
|
|
| |
from SystemZFrameLowering.
llvm-svn: 212123
|
| |
|
|
|
|
|
|
|
| |
llvm::DISubprograms
Update DeadArgumentElimintation to use this, with the intent of reusing
the functionality for ArgumentPromotion as well.
llvm-svn: 212122
|
| |
|
|
| |
llvm-svn: 212120
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The logic for expanding atomics that aren't natively supported in
terms of cmpxchg loops is much simpler to express at the IR level. It
also allows the normal optimisations and CodeGen improvements to help
out with atomics, instead of using a limited set of possible
instructions..
rdar://problem/13496295
llvm-svn: 212119
|
| |
|
|
|
|
|
|
|
| |
For now I only updated the _alt variants. The main variants are used by
codegen and that will need a bit more work to trigger.
<rdar://problem/17492620>
llvm-svn: 212114
|
| |
|
|
|
|
|
|
|
| |
Adding a writemask variant would require a third asm string to be passed to
the template. Generate the AsmString in the template instead.
No change in X86.td.expanded.
llvm-svn: 212113
|
| |
|
|
|
|
|
|
| |
This reverts commit r212088, which is causing a number of spec
failures. Will provide reduced test cases shortly.
PR20057
llvm-svn: 212109
|
| |
|
|
|
|
| |
Spotted by Amara Emerson.
llvm-svn: 212106
|
| |
|
|
|
|
|
|
|
| |
There were transforms whose *intent* was to downgrade the linkage of
external objects to have internal linkage.
However, it fired on things with private linkage as well.
llvm-svn: 212104
|
| |
|
|
|
|
|
|
| |
This is a small targeted fix for pr20119. The code needs quiet a bit of
refactoring and I added some FIXMEs about it, but I want to get the testcase
passing first.
llvm-svn: 212101
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
copies.
This patch extends the peephole optimization introduced in r190713 to produce
register-coalescer friendly copies when possible.
This extension taught the existing cross-bank copy optimization how to deal
with the instructions that generate cross-bank copies, i.e., insert_subreg,
extract_subreg, reg_sequence, and subreg_to_reg.
E.g.
b = insert_subreg e, A, sub0 <-- cross-bank copy
...
C = copy b.sub0 <-- cross-bank copy
Would produce the following code:
b = insert_subreg e, A, sub0 <-- cross-bank copy
...
C = copy A <-- same-bank copy
This patch also introduces a new helper class for that: ValueTracker.
This class implements the logic to look through the copy related instructions
and get the related source.
For now, the advanced rewriting is disabled by default as we are lacking the
semantic on target specific instructions to catch the motivating examples.
Related to <rdar://problem/12702965>.
llvm-svn: 212100
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
By default, no functionality change.
Before evicting a local variable, this heuristic tries to find another (set of)
local(s) that can be reassigned to a free color.
In some extreme cases (large basic blocks with tons of local variables), the
compilation time is dominated by the local interference checks that this
heuristic must perform, with no code gen gain.
E.g., the motivating example takes 4 minutes to compile with this heuristic, 12
seconds without.
Improving the situation will likely require to make drastic changes to the
register allocator and/or the interference check framework.
For now, provide this flag to better understand the impact of that heuristic.
<rdar://problem/17444599>
llvm-svn: 212099
|
| |
|
|
|
|
|
| |
This was kept around "for compatibility through 2.6" in 2009 and is not used or
tested.
llvm-svn: 212095
|
| |
|
|
|
|
|
|
|
|
|
| |
instructions within a function, lead to the function itself."
This reverts commit r212085.
This breaks the sanitizer bot... & I thought I'd tried pretty hard not
to do that. Guess I need to try harder.
llvm-svn: 212089
|
| |
|
|
|
|
| |
Fixes another test case under PR20057.
llvm-svn: 212088
|
| |
|
|
|
|
|
|
|
|
|
| |
ForceInterpreter=false shouldn't disable the interpreter completely because it
can still be necessary to interpret if the target doesn't support JIT.
No obvious way to test this in LLVM, but this matches what
LLVMCreateExecutionEngineForModule() does and fixes the clang-interpreter
example in the clang source tree which uses the ExecutionEngine.
llvm-svn: 212086
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
within a function, lead to the function itself.
Originally committed in r211723, reverted in r211724 due to failure
cases found and fixed (ArgumentPromotion: r211872, Inlining: r212065),
and I now believe the invariant actually holds for some reasonable
amount of code (but I'll keep an eye on the buildbots and see what
happens... ).
Original commit message:
PR20038: DebugInfo: Inlined call sites where the caller has debug info
but the call itself has no debug location.
This situation does bad things when inlined, so I've fixed Clang not to
produce inlinable call sites without locations when the caller has debug
info (in the one case where I could find that this occurred). This
updates the PR20038 test case to be what clang now produces, and readds
the assertion that had to be removed due to this bug.
I've also beefed up the debug info verifier to help diagnose these
issues in the future, and I hope to add checks to the inliner to just
assert-fail if it encounters this situation. If, in the future, we
decide we have to cope with this situation, the right thing to do is
probably to just remove all the DebugLocs from the inlined instructions.
llvm-svn: 212085
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
seh_stackalloc 0 is not representable in Win64 SEH info, so emitting it
is a bug.
Reviewers: rnk
Differential Revision: http://reviews.llvm.org/D4334
Patch by Vadim Chugunov!
llvm-svn: 212081
|
| |
|
|
|
|
|
| |
An alias with an aliasee of a non-zero GEP is not trivially replacable
with it's aliasee.
llvm-svn: 212079
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Inlining functions with block addresses can cause many problem and requires a
rich infrastructure to support including escape analysis. At this point the
safest approach to address these problems is by blocking inlining from
happening.
Background:
There have been reports on Ruby segmentation faults triggered by inlining
functions with block addresses like
//Ruby code snippet
vm_exec_core() {
finish_insn_seq_0 = &&INSN_LABEL_finish;
INSN_LABEL_finish:
;
}
This kind of scenario can also happen when LLVM picks a subset of blocks for
inlining, which is the case with the actual code in the Ruby environment.
LLVM suppresses inlining for such functions when there is an indirect branch.
The attached patch does so even when there is no indirect branch. Note that
user code like above would not make much sense: using the global for jumping
across function boundaries would be illegal.
Why was there a segfault:
In the snipped above the block with the label is recognized as dead So it is
eliminated. Instead of a block address the cloner stores a constant (sic!) into
the global resulting in the segfault (when the global is used in a goto).
Why had it worked in the past then:
By luck. In older versions vm_exec_core was also inlined but the label address
used was the block label address in vm_exec_core. So the global jump ended up
in the original function rather than in the caller which accidentally happened
to work.
Test case ./tools/clang/test/CodeGen/indirect-goto.c will fail as a result
of this commit.
rdar://17245966
llvm-svn: 212077
|