Craig Topper [Sat, 10 Oct 2015 18:54:26 +0000 (18:54 +0000)]
In isUIntN, make sure N is less than 64 before using in a shift to avoid undefined behavior. Also change it to use the same formula as the template version which I think results in less math in compiled code.
Teresa Johnson [Sat, 10 Oct 2015 14:18:36 +0000 (14:18 +0000)]
Fix PR25101 - Handle anonymous functions without VST entries
Summary:
The change to use the VST function entries for lazy deserialization did
not handle the case of anonymous functions without aliases. In that case
we must fall back to scanning the function blocks as there is no VST
entry.
Keno Fischer [Sat, 10 Oct 2015 05:37:02 +0000 (05:37 +0000)]
[RuntimeDyld] Fix performance problem in resolveRelocations with many sections
Summary:
Rather than just iterating over all sections and checking whether we have relocations for them, iterate over the relocation map instead. This showed up heavily in an artificial julia benchmark that does lots of compilation. On that particular benchmark, this patch gives
~15% performance improvements. As far as I can tell the primary reason why the original
loop was so expensive is that Relocations[i] actually constructs a relocationList (allocating memory & doing lots of other unnecessary computing) if none is found.
Remove implicit ilist iterator conversions from LLVMAnalysis.
I came across something really scary in `llvm::isKnownNotFullPoison()`
which relied on `Instruction::getNextNode()` being completely broken
(not surprising, but scary nevertheless). This function is documented
(and coded to) return `nullptr` when it gets to the sentinel, but with
an `ilist_half_node` as a sentinel, the sentinel check looks into some
other memory and we don't recognize we've hit the end.
Rooting out these scary cases is the reason I'm removing the implicit
conversions before doing anything else with `ilist`; I'm not at all
surprised that clients rely on badness.
I found another scary case -- this time, not relying on badness, just
bad (but I guess getting lucky so far) -- in
`ObjectSizeOffsetEvaluator::compute_()`. Here, we save out the
insertion point, do some things, and then restore it. Previously, we
let the iterator auto-convert to `Instruction*`, and then set it back
using the `Instruction*` version:
if (PrevInsertPoint)
Builder.SetInsertPoint(PrevInsertPoint);
The check for `PrevInsertPoint` doesn't protect correctly against bad
accesses. If the insertion point has been set to the end of a basic
block (i.e., `SetInsertPoint(SomeBB)`), then `GetInsertPoint()` returns
an iterator pointing at the list sentinel. The version of
`SetInsertPoint()` that's getting called will then call
`PrevInsertPoint->getParent()`, which explodes horribly. The only
reason this hasn't blown up is that it's fairly unlikely the builder is
adding to the end of the block; usually, we're adding instructions
somewhere before the terminator.
Kevin Enderby [Sat, 10 Oct 2015 00:05:01 +0000 (00:05 +0000)]
Fix a bugs in the Mach-O disassembler when disassembling from a
malformed Mach-O file that caused a crash. This was because of an
assert where the code was incorrectly attempting to parse relocation
entries off of the sections and the filetype was not an MH_OBJECT.
Reid Kleckner [Fri, 9 Oct 2015 23:34:53 +0000 (23:34 +0000)]
[WinEH] Delete the old landingpad implementation of Windows EH
The new implementation works at least as well as the old implementation
did.
Also delete the associated preparation tests. They don't exercise
interesting corner cases of the new implementation. All the codegen
tests of the EH tables have already been ported.
Chris Bieneman [Fri, 9 Oct 2015 22:26:04 +0000 (22:26 +0000)]
[CMake] Parallel make breaks on native tablegen
Patch by Alex Wang
This patch resolves a parallelization issue that occurs when native tablegen targets are built at the same time. They both try to build libSupport and clobber each other causing the builds to fail.
David Majnemer [Fri, 9 Oct 2015 22:18:45 +0000 (22:18 +0000)]
[WinEH] Insert the catchpad return before CSR restoration
x64 catchpads use rax to inform the unwinder where control should go
next. However, we must initialize rax before the epilogue sequence so
as to not perturb the unwinder.
James Y Knight [Fri, 9 Oct 2015 21:36:19 +0000 (21:36 +0000)]
Fix assert when emitting llvm.pow.f86.
This occurred due to introducing the invalid i64 type after type
legalization had already finished, in an attempt to workaround bitcast
f64 -> v2i32 not doing constant folding.
The *right* thing is to actually fix bitcast, but that has other
complications. So, for now, just get rid of the broken workaround, and
check in a test-case showing that it doesn't crash, with TODOs for
emitting proper code.
Reid Kleckner [Fri, 9 Oct 2015 20:39:39 +0000 (20:39 +0000)]
[SEH] Remember to emit the last invoke range for SEH
This wasn't very observable in execution tests, because usually there is
an invoke in the catchpad that unwinds the the catchendpad but never
actually throws.
James Y Knight [Fri, 9 Oct 2015 20:10:14 +0000 (20:10 +0000)]
Fix assert in X86 backend.
When running combine on an extract_vector_elt, it wants to look through
a bitcast to check if the argument to the bitcast was itself an
extract_vector_elt with particular operands.
However, it called getOperand() on the argument to the bitcast *before*
checking that the opcode was EXTRACT_VECTOR_ELT, assert-failing if there
were zero operands for the actual opcode.
CodeGen: Remove implicit iterator conversions from MBB.cpp
Remove implicit ilist iterator conversions from MachineBasicBlock.cpp.
I've also added an overload of `splice()` that takes a pointer, since
it's a natural API. This is similar to the overloads I added for
`remove()` and `erase()` in r249867.
Owen Anderson [Fri, 9 Oct 2015 18:40:20 +0000 (18:40 +0000)]
Teach LoopUnswitch not to perform non-trivial unswitching on loops containing convergent operations.
Doing so could cause the post-unswitching convergent ops to be
control-dependent on the unswitch condition where they were not before.
This check could be refined to allow unswitching where the convergent
operation was already control-dependent on the unswitch condition.
CodeGen: Remove implicit iterator conversions from SlotIndexes.h, NFC
Be explicit about changes between pointers and iterators, as with other
recent commits. This transitively removes implicit ilist iterator
conversions from about 20 source files in CodeGen.
CodeGen: Remove implicit conversions from Analysis and BranchFolding
Remove a few more implicit ilist iterator conversions, this time from
Analysis.cpp and BranchFolding.cpp.
I added a few overloads for `remove()` and `erase()`, which quite
naturally take pointers as well as iterators as parameters. This will
reduce the churn at least in the short term, but I don't really have a
problem with these existing for longer.
Owen Anderson [Fri, 9 Oct 2015 18:06:13 +0000 (18:06 +0000)]
Refine the definition of convergent to only disallow the addition of new control dependencies.
This covers the common case of operations that cannot be sunk.
Operations that cannot be hoisted should already be handled properly via
the safe-to-speculate rules and mechanisms.
Diego Novillo [Fri, 9 Oct 2015 17:54:24 +0000 (17:54 +0000)]
Add inline stack streaming to binary sample profiles.
With this patch we can now read and write inline stacks in sample
profiles to the binary encoded profiles.
In a subsequent patch, I will add a string table to the binary encoding.
Right now function names are emitted as strings every time we find them.
This is too bloated and will produce large files in applications with
lots of inlining.
AArch64: Make getNextNode() cleanup in r249764 more clear
After r249764, if you didn't see the full context, it looked like
`std::next(I)` would get the same result as
`++MachineBasicBlock::iterator(I)`. However, `I` is a `MachineInstr*`
(not a `MachineBasicBlock::iterator`).
Use the `getIterator()` helper I added later (r249782) to make this code
more clear.
Revert "Support: Partially revert r249782 to unbreak clang build"
This reverts commit r249783, fully reinstating r249782. I've fixed the
bug in clang: it was a non-const iterator that dereferenced to const
(but had an implicit conversion to non-const).
Dehao Chen [Fri, 9 Oct 2015 16:50:16 +0000 (16:50 +0000)]
Make HeaderLineno a local variable.
http://reviews.llvm.org/D13576
As we are using hierarchical profile, there is no need to keep HeaderLineno a member variable. This is because each level of the inline stack will have its own header lineno. One should use the head lineno of its own inline stack level instead of the actual symbol.
Kevin Enderby [Fri, 9 Oct 2015 16:48:44 +0000 (16:48 +0000)]
Fixed two bugs in llvm-objdump’s printing of Objective-C meta data
from malformed Mach-O files that caused crashes. The first because the
offset in a dyld bind table entry was out of range. The second because their
was no image info section and the routine printing it did not have the
need check to see the section did not exist.
Vector element extraction without stack operations on Power 8
This patch corresponds to review:
http://reviews.llvm.org/D12032
This patch builds onto the patch that provided scalar to vector conversions
without stack operations (D11471).
Included in this patch:
- Vector element extraction for all vector types with constant element number
- Vector element extraction for v16i8 and v8i16 with variable element number
- Removal of some unnecessary COPY_TO_REGCLASS operations that ended up
unnecessarily moving things around between registers
Not included in this patch (will be in upcoming patch):
- Vector element extraction for v4i32, v4f32, v2i64 and v2f64 with
variable element number
- Vector element insertion for variable/constant element number
Testing is provided for all extractions. The extractions that are not
implemented yet are just placeholders.
[MemCpyOpt] Fix wrong merging adjacent nontemporal stores into memset calls.
Pass MemCpyOpt doesn't check if a store instruction is nontemporal.
As a consequence, adjacent nontemporal stores are always merged into a
memset call.
Example:
;;;
define void @foo(<4 x float>* nocapture %p) {
entry:
store <4 x float> zeroinitializer, <4 x float>* %p, align 16, !nontemporal !0
%p1 = getelementptr inbounds <4 x float>, <4 x float>* %dst, i64 1
store <4 x float> zeroinitializer, <4 x float>* %p1, align 16, !nontemporal !0
ret void
}
!0 = !{i32 1}
;;;
In this example, the two nontemporal stores are combined to a memset of zero
which does not preserve the nontemporal hint. Later on the backend (tested on a
x86-64 corei7) expands that memset call into a sequence of two normal 16-byte
aligned vector stores.
With this patch, we no longer merge nontemporal stores into calls to memset.
In this example, llc correctly expands the two stores into two movntps:
xorps %xmm0, %xmm0
movntps %xmm0, 16(%rdi)
movntps %xmm0, (%rdi)
In theory, we could extend the usage of !nontemporal metadata to memcpy/memset
calls. However a change like that would only have the effect of forcing the
backend to expand !nontemporal memsets back to sequences of store instructions.
A memset library call would not have exactly the same semantic of a builtin
!nontemporal memset call. So, SelectionDAG will have to conservatively expand
it back to a sequence of !nontemporal stores (effectively undoing the merging).
Jonas Paulsson [Fri, 9 Oct 2015 07:19:16 +0000 (07:19 +0000)]
[SystemZ] Minor bugfixes.
LLCH, LLHH and CLIH had the wrong register classes for the def-operand.
Tie operands if changing opcode to an instruction with tied ops.
Comment typo fix.
These fixes were needed in order to make regression test case
SystemZ/asm-18.ll pass with -verify-machineinstrs (not used by
default).
Jonas Paulsson [Fri, 9 Oct 2015 07:19:12 +0000 (07:19 +0000)]
[SystemZ] Bugfix in SystemZAsmParser.cpp.
Let parseRegister() allow RegFP Group if expecting RegV Group, since the
%f register prefix yields the FP group even while used with vector instructions.
Accept r11 when targeting Windows on ARM rather than just low registers.
Because we are in a thumb-2 only mode, this may be slightly more expensive in
code size, but results in better code for the environment since it spills the
frame register, which is generally desired for fast stack walking as per the
ABI.
Sanjoy Das [Fri, 9 Oct 2015 02:44:45 +0000 (02:44 +0000)]
[SCEV] Call `StrengthenNoWrapFlags` after `GroupByComplexity`; NFCI
The current implementation of `StrengthenNoWrapFlags` is agnostic to the
order of `Ops`, so this commit should not change anything semantic. An
upcoming change will make `StrengthenNoWrapFlags` sensitive to the order
of `Ops`.
Summary:
- Recurse from cleanupendpads to their cleanuppads, to make sure the
cleanuppad is visited if it has a cleanupendpad but no cleanupret.
- Check for and avoid double-processing cleanuppads, to allow for them to
have multiple cleanuprets (plus cleanupendpads).
- Update Cxx state numbering to visit toplevel cleanupendpads and to
recurse from cleanupendpads to their preds, to ensure we number any
funclets in inlined cleanups. SEH state numbering already did this.
Reid Kleckner [Fri, 9 Oct 2015 00:15:01 +0000 (00:15 +0000)]
[llvm-symbolizer] Make --relative-address work with DWARF contexts
Summary:
Previously the relative address flag only affected PDB debug info. Now
both DIContext implementations always expect to be passed virtual
addresses. llvm-symbolizer is now responsible for adding ImageBase to
module offsets when --relative-offset is passed.
Support: Partially revert r249782 to unbreak clang build
Apparently the iterators in `clang::CFGBlock` have an auto-conversion to
`CFGBlock *`, but the dereference operator gives `const CFGBlock &`.
Until I have a moment to fix that, revert the GenericDomTree chagnes
from r249782.
IR: Remove implicit iterator conversions from lib/IR, NFC
Stop converting implicitly between iterators and pointers/references in
lib/IR. For convenience, I've added a `getIterator()` accessor to
`ilist_node` so that callers don't need to know how to spell the
iterator class (i.e., they can use `X.getIterator()` instead of
`Function::iterator(X)`).
I'll eventually disallow these implicit conversions entirely, but
there's a lot of code, so it doesn't make sense to do it all in one
patch. One library or so at a time.
Why? To root out cases of `getNextNode()` and `getPrevNode()` being
used in iterator logic. The design of `ilist` makes that invalid when
the current node could be at the back of the list, but it happens to
"work" right now because of a bug where those functions never return
`nullptr` if you're using a half-node sentinel. Before I can fix the
function, I have to remove uses of it that rely on it misbehaving.
(Maybe the function should just be deleted anyway? But I don't want
deleting it -- potentially a huge project -- to block fixing
ilist/iplist.)
Sanjoy Das [Thu, 8 Oct 2015 23:18:33 +0000 (23:18 +0000)]
[IRBuilder] Change the `gc.statepoint` creation interface
This is to enable me to address review for D13491 -- `Flags` is a
bitfield of `StatepointFlags`, not an individual item out of the enum,
so it should be represented as an `uint32_t`.
Kevin Enderby [Thu, 8 Oct 2015 22:50:55 +0000 (22:50 +0000)]
Fix a bug in llvm-objdump’s printing of Objective-C meta data
from malformed Mach-O files that caused a crash because of a
section header had a size that extended past the end of the file.
Support: Stop relying on iterator auto-conversion, NFC
Stop relying on ilist implicit conversions from `value_type&` to
`iterator` in YAMLParser.cpp.
I eventually want to outlaw this entirely. It encourages
`getNextNode()` and `getPrevNode()` in iterator logic, which is
extremely fragile (and relies on them never returning `nullptr`).
FTR, there's nothing nefarious going on in this case, it was just easy
to clean up since the callers really wanted iterators to begin with.
Stop using `getNextNode()` to get an insertion point (at least, in this
one place). Instead, use iterator logic directly.
The `getNextNode()` interface isn't actually supposed to work for
creating iterators; it's supposed to return `nullptr` (not a real
iterator) if this is the last node. It's currently broken and will
"happen" to work, but if we ever fix the function, we'll get some
strange failures in places like this.
Stop using `getNextNode()` to get an iterator to a fragment (at least,
in this one place). Instead, use iterator logic directly.
The `getNextNode()` interface isn't actually supposed to work for
creating iterators; it's supposed to return `nullptr` (not a real
iterator) if this is the last node. It's currently broken and will
"happen" to work, but if we ever fix the function, we'll get some
strange failures in places like this.
Frederic Riss [Thu, 8 Oct 2015 22:35:53 +0000 (22:35 +0000)]
[dsymutil] Try to find lipo first besides dsymutil before looking up the PATH.
Even if we don't have it in PATH, lipo should usually exist in the same directory
as dsymutil. Keep the fallback looking up the PATH, it's very useful when
testing a non-installed executable.
PowerPC: Don't use getNextNode() for insertion point
Stop using `getNextNode()` to create an insertion point for machine
instructions (at least, in this one place). Instead, use an iterator.
As a drive-by, clean up dump statements to use iterator logic.
The `getNextNode()` interface isn't actually supposed to work for
insertion points; it's supposed to return `nullptr` if this is the last
node. It's currently broken and will "happen" to work, but if we ever
fix the function, we'll get some strange failures.
This is an implementation of
https://github.com/google/sanitizers/issues/579
It has a number of advantages over the current mapping:
* Works for non-PIE executables.
* Does not require ASLR; as a consequence, debugging MSan programs in
gdb no longer requires "set disable-randomization off".
* Supports linux kernels >=4.1.2.
* The code is marginally faster and smaller.
This is an ABI break. We never really promised ABI stability, but
this patch includes a courtesy escape hatch: a compile-time macro
that reverts back to the old mapping layout.
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
Diego Novillo [Thu, 8 Oct 2015 19:40:37 +0000 (19:40 +0000)]
Re-apply r249644: Handle inline stacks in gcov-encoded sample profiles.
This fixes memory allocation problems by making the merge operation keep
the profile readers around until the merged profile has been emitted.
This is needed to prevent the inlined function names to disappear from
the function profiles. Since all the names are kept as references, once
the reader disappears, the names are also deallocated.
Additionally, XFAIL on big-endian architectures. The test case uses a
gcov file generated on a little-endian system.
projects / llvm / log