verifying that the types from that module don't
override types from DWARF. Also added a target setting
to LLDB so we can tell Clang where to look for these
local modules.
<rdar://problem/18805055>
llvm-svn: 234016
When enabling PPC64LE, I disabled some optimizations of BUILD_VECTOR
nodes for little endian because wrong results were produced. I've
subsequently investigated and found this is due to a call to
BuildVectorSDNode::isConstantSplat that was always specifying
big-endian. With this changed to correctly identify the target
endianness, the optimizations work as expected.
I found another case of a call to the same method with big-endian
hardcoded, in PPC::isAllNegativeZeroVector(). I discovered this was
an orphaned method with no callers, so I've just removed it.
The existing test/CodeGen/PowerPC/vec_constants.ll checks these
optimizations, so for testing I've just added a variant for little
endian.
llvm-svn: 234011
This patch provides implementation of R_ARM_TARGET1 relocation with
configuration of its behaviour from a command line. This patch provides
two command line options for GnuLd driver: --arm-target1-rel and
--arm-target1-abs (similar to ld option names with extra prefix 'arm-').
So user may choose which behaviour of R_ARM_TARGET1 is preferred for his
implementation of libc.
Differential Revision: http://reviews.llvm.org/D8707
llvm-svn: 234009
This patch attempts to fold the shuffling of 'scalar source' inputs - BUILD_VECTOR and SCALAR_TO_VECTOR nodes - if the shuffle node is the only user. This folds away a lot of unnecessary shuffle nodes, and allows quite a bit of constant folding that was being missed.
Differential Revision: http://reviews.llvm.org/D8516
llvm-svn: 234004
Fixes PR19582.
Previously, when an asm assignment (.set or =) was created, we would look up
the section immediately in MCSymbol::setVariableValue. This caused symbols
to receive the wrong section if the RHS of the assignment had not been seen
yet. This had a knock-on effect in the object file emitters, causing them
to emit extra symbols, or to give symbols the wrong visibility or the wrong
section. For example, in the following asm:
.data
.Llocal:
.text
leaq .Llocal1(%rip), %rdi
.Llocal1 = .Llocal2
.Llocal2 = .Llocal
the first assignment would give .Llocal1 a null section, which would never get
fixed up by the second assignment. This would cause the ELF object file emitter
to consider .Llocal1 to be an undefined symbol and give it external linkage,
even though .Llocal1 should not have been emitted at all in the object file.
Or in the following asm:
alias_to_local = Ltmp0
Ltmp0:
the Mach-O object file emitter would give the alias_to_local symbol a n_type
of N_SECT and a n_sect of 0. This is invalid under the Mach-O specification,
which requires N_SECT symbols to receive a non-zero section number if the
symbol is defined in a section in the object file.
https://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/MachORuntime/#//apple_ref/c/tag/nlist
After this change we do not look up the section when the assignment is created,
but instead look it up on demand and store it in Section, which is treated
as a cache if the symbol is a variable symbol.
This change also fixes a bug in MCExpr::FindAssociatedSection. Previously,
if we saw a subtraction, we would return the first referenced section, even in
cases where we should have been returning the absolute pseudo-section. Now we
always return the absolute pseudo-section for expressions that subtract two
section-derived expressions. This isn't always correct (e.g. if one of the
sections ends up being laid out at an absolute address), but it's probably
the best we can do without more context.
This allows us to remove code in two places where we appear to have been
working around this bug, in MachObjectWriter::markAbsoluteVariableSymbols
and in X86AsmPrinter::EmitStartOfAsmFile.
Re-applies r233595 (aka D8586), which was reverted in r233898.
Differential Revision: http://reviews.llvm.org/D8798
llvm-svn: 233995
Summary:
Same as the last patch, but for BasicBlock
(Requires same code movement)
Reviewers: chandlerc
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D8801
llvm-svn: 233992
Summary:
Updated test to reflect that Linux and Darwin behave the same now.
Removed @expectedFailureLinux for passing tests.
Test Plan: run tests
Reviewers: clayborg, sivachandra
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D8678
llvm-svn: 233989
DWARF types and types from modules can coexist even
if they have the same name and refer to two different
things.
<rdar://problem/18805055>
llvm-svn: 233988
Register coalescing can change the target of a RegPair hint to a
physreg, we should not crash on this. This also slightly improved the
way ARMBaseRegisterInfo::updateRegAllocHint() works.
llvm-svn: 233987
Summary:
Currently there are bugs in out detection of multi-level pointer conversions and pointer to member conversions. This patch fixes the following issues.
* Allow multi-level pointers with different nested qualifiers.
* Allow multi-level mixed pointers to objects and pointers to members with different nested qualifiers.
* Allow conversions from `int Base::*` to `int Derived::*` but only for non-nested pointers.
There is still some work that needs to be done to clean this patch up but I want to get some input on it.
Open questions:
* Does `__pointer_to_member_type_info::can_catch(...)` need to adjust the pointer if a base to derived conversion is performed?
Reviewers: danalbert, compnerd, mclow.lists
Reviewed By: mclow.lists
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D8758
llvm-svn: 233984
This prevents us from running out of registers in the backend.
Introducing stack malloc calls prevents the backend from recognizing the
inline asm operands as stack objects. When the backend recognizes a
stack object, it doesn't need to materialize the address of the memory
in a physical register. Instead it generates a simple SP-based memory
operand. Introducing a stack malloc forces the backend to find a free
register for every memory operand. 32-bit x86 simply doesn't have enough
registers for this to succeed in most cases.
Reviewers: kcc, samsonov
Differential Revision: http://reviews.llvm.org/D8790
llvm-svn: 233979
Summary:
The old requirement on GEP candidates being in bounds is unnecessary.
For off-bound GEPs, we still have
&B[i * S] = B + (i * S) * e = B + (i * e) * S
Test Plan: slsr_offbound_gep in slsr-gep.ll
Reviewers: meheff
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D8809
llvm-svn: 233949
result_type is always ErrorOr<unique_ptr<File>>, and since the type traits
is for instantiating ELF files, it's unlikely that we want to return
something else. This patch removes that type.
llvm-svn: 233948
This makes it possible to use the same representation of llvm.eh.actions
in outlined handlers as we use in the parent function because i32's are
just constants that can be copied freely between functions.
I had to add a sentinel alloca to the list of child allocas so that we
don't try to sink the catch object into the handler. Normally, one would
use nullptr for this kind of thing, but TinyPtrVector doesn't support
null elements. More than that, it's elements have to have a suitable
alignment. Therefore, I settled on this for my sentinel:
AllocaInst *getCatchObjectSentinel() {
return static_cast<AllocaInst *>(nullptr) + 1;
}
llvm-svn: 233947
The test class 'G' reads and writes to the same static variables in its
constructor, destructor and call operator. When threads are
constructed using `std::thread t((G()))` there is a race condition between the
destruction of the temporary and the execution of `G::operator()()`.
The fix is to simply create the input before creating the thread.
llvm-svn: 233946
Summary:
The summary of the bug, provided by Stephan T. Lavavej:
In shared_timed_mutex::try_lock_until() (line 195 in 3.6.0), you need to deliver a notification. The scenario is:
* There are N threads holding the shared lock.
* One thread calls try_lock_until() to attempt to acquire the exclusive lock. It sets the "I want to write" bool/bit, then waits for the N readers to drain away.
* K more threads attempt to acquire the shared lock, but they notice that someone said "I want to write", so they block on a condition_variable.
* At least one of the N readers is stubborn and doesn't release the shared lock.
* The wannabe-writer times out, gives up, and unsets the "I want to write" bool/bit.
At this point, a notification (it needs to be notify_all) must be delivered to the condition_variable that the K wannabe-readers are waiting on. Otherwise, they can block forever without waking up.
Reviewers: mclow.lists, jyasskin
Reviewed By: jyasskin
Subscribers: jyasskin, cfe-commits
Differential Revision: http://reviews.llvm.org/D8796
llvm-svn: 233944
There were a couple of real bugs here regarding error checking and
signed/unsigned comparisons, but mostly these were just noise.
There was one class of bugs fixed here which is particularly
annoying, dealing with MSVC's non-standard behavior regarding
the underlying type of enums. See the comment in
lldb-enumerations.h for details. In short, from now on please use
FLAGS_ENUM and FLAGS_ANONYMOUS_ENUM when defining enums which
contain values larger than can fit into a signed integer.
llvm-svn: 233943
Without this patch, we split the 256-bit vector into halves and produced something like:
movzwl (%rdi), %eax
vmovd %eax, %xmm0
vxorps %xmm1, %xmm1, %xmm1
vblendps $15, %ymm0, %ymm1, %ymm0 ## ymm0 = ymm0[0,1,2,3],ymm1[4,5,6,7]
Now, we eliminate the xor and blend because those zeros are free with the vmovd:
movzwl (%rdi), %eax
vmovd %eax, %xmm0
This should be the final fix needed to resolve PR22685:
https://llvm.org/bugs/show_bug.cgi?id=22685
llvm-svn: 233941
Require the pointee type to be passed explicitly and assert that it is
correct. For now it's possible to pass nullptr here (and I've done so in
a few places in this patch) but eventually that will be disallowed once
all clients have been updated or removed. It'll be a long road to get
all the way there... but if you have the cahnce to update your callers
to pass the type explicitly without depending on a pointer's element
type, that would be a good thing to do soon and a necessary thing to do
eventually.
llvm-svn: 233938
Now the GEP constant utility functions require the type to be explicitly
passed (since eventually the pointer type will be opaque and not convey
the required type information). For now callers can still pass nullptr
(though none were needed here in Clang, which is nice) if
convenienc/necessary, but eventually that will be disallowed as well.
llvm-svn: 233937
Guard against this by setting a new "m_finalizing" flag that lets us know we are in the process of finalizing.
<rdar://problem/20369152>
llvm-svn: 233935
Sanjay Patel