TagDecls (structs, enums, etc.) may have the same name for linkage
purposes of one another; to disambiguate, we add a number to the mangled
named. However, we didn't do this if the TagDecl has a pseudo-name for
linkage purposes (it was defined alongside a DeclaratorDecl or a
TypeNameDecl).
This fixes PR24651.
llvm-svn: 246659
This is a continuation of the fix from:
http://reviews.llvm.org/D10662
and discussion in:
http://reviews.llvm.org/D12154
Here, we distinguish slow unaligned SSE (128-bit) accesses from slow unaligned
scalar (64-bit and under) accesses. Other lowering (eg, getOptimalMemOpType)
assumes that unaligned scalar accesses are always ok, so this changes
allowsMisalignedMemoryAccesses() to match that behavior.
Differential Revision: http://reviews.llvm.org/D12543
llvm-svn: 246658
Summary: loop-convert no longer crashes when calling a member function using a member pointer which is a member of another record.
Reviewers: alexfh, klimek
Subscribers: cfe-commits, klimek
Differential Revision: http://reviews.llvm.org/D12555
llvm-svn: 246655
Summary:
Add the necessary plumbing so that llvm_token_ty can be used as an
argument/return type in intrinsic definitions and correspondingly require
TokenTy in function types. TokenTy is an opaque type that has no target
lowering, but can be used in machine-independent intrinsics. It is
required for the upcoming llvm.eh.padparam intrinsic.
Reviewers: majnemer, rnk
Subscribers: stoklund, llvm-commits
Differential Revision: http://reviews.llvm.org/D12532
llvm-svn: 246651
This fixes a regression caused by r245645 where creating alternative
thumb disassembler was enabled even when the main disassembler is
already thumb.
llvm-svn: 246649
If no architecture is defined for the disassambler command then it uses
the architecture of the target. In case of arm it will be "arm" what is
treated as the oldest arm version by the LLVM disassambler causing a lot
of invalid opcode in the output.
This change forces the use of "armv8.1a" (the newest arm architecture) if
no sub architecure was specified (either by the user or by the target) to
disassamble all instruction.
Differential revision: http://reviews.llvm.org/D12553
llvm-svn: 246648
If a command argument contains a space then it have to be escaped with
backslash signs so the argument parsing logic can parse it properly.
This CL fixes the tab completion code for the arguments to create
complitions with correctly escaped strings.
Differential revision: http://reviews.llvm.org/D12531
llvm-svn: 246639
Summary: Fix a bug where use-auto check would crash when the definition of a type is in the same statement than its instantiation with new.
Reviewers: alexfh
Subscribers: cfe-commits, klimek
Differential Revision: http://reviews.llvm.org/D12551
llvm-svn: 246638
We were bailing to two places if our runtime checks failed. If the initial overflow check failed, we'd go to ScalarPH. If any other check failed, we'd go to MiddleBlock. This caused us to have to have an extra PHI per induction and reduction as the vector loop's exit block was not dominated by its latch.
There's no need to have this behavior - if we just always go to ScalarPH we can get rid of a bunch of complexity.
llvm-svn: 246637
This reduces the complexity of createEmptyBlock() and will open the door to further refactoring.
The test change is simply because we're now constant folding a trivial test.
llvm-svn: 246634
It makes things easier to understand if this is in a helper method. This is part of my ongoing spaghetti-removal operation on createEmptyLoop.
llvm-svn: 246632
There's no need to widen canonical induction variables. It's just as efficient to create a *new*, wide, induction variable.
Consider, if we widen an indvar, then we'll have to truncate it before its uses anyway (1 trunc). If we create a new indvar instead, we'll have to truncate that instead (1 trunc) [besides which IndVars should go and clean up our mess after us anyway on principle].
This lets us remove a ton of special-casing code.
llvm-svn: 246631
Vectorized loops only ever have one induction variable. All induction PHIs from the scalar loop are rewritten to be in terms of this single indvar.
We were trying very hard to pick an indvar that already existed, even if that indvar wasn't canonical (didn't start at zero). But trying so hard is really fruitless - creating a new, canonical, indvar only results in one extra add in the worst case and that add is trivially easy to push through the PHI out of the loop by instcombine.
If we try and be less clever here and instead let instcombine clean up our mess (as we do in many other places in LV), we can remove unneeded complexity.
llvm-svn: 246630
Summary:
The test (among other things) attempts to verify that detaching works while the inferior is
running. However, this was racy since the inferior could end up stopping again before we got a
chance to detach from it (the test could be made to fail reliably by inserting a sleep just after
the last "continue" command). The reason for the stop was that we had a breakpoint set in a place
that can be hit by multiple threads, and we stop because another thread hit a breakpoint.
I fix this by moving the breakpoint to a place that is reachable from only one thread. I also
make sure that the same thread cannot hit the breakpoint if we are exceptionaly slow by flipping
a flag which makes the breakpoint unreachable (I cannot just disable or delete the breakpoint as
the test makes it a point to try detaching while breakpoints are still set).
Another source or racyness was that the test verified that the process resumes and
stops after a "continue". However, if these two events happened too fast, the initial start event
would be lost, and the test would end up confused. I have implemented this in a safer manner and
made a utility function out of it, as I know of a couple of other tests which need the same
functionality.
Reviewers: zturner, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12527
llvm-svn: 246623
Vector 'getelementptr' with scalar base is an opportunity for gather/scatter intrinsic to generate a better sequence.
While looking for uniform base, we want to use the scalar base pointer of GEP, if exists.
Differential Revision: http://reviews.llvm.org/D11121
llvm-svn: 246622
I don't understand why the previous code is pretty flaky and
the new code is at least less flaky, but the original test
occasionally failed on the second run of lib.exe.
My guess was that lib.exe was failing because the output of
the echo command executed immediately before lib.exe was not
flushed to a file, but as far as I can say, the file
descriptor is properly closed in TestRunner.py, so this's
probably not correct. Other theory is that, on Windows, file
output is not guaranteed to be visible to other processes even
if a process flushes file descriptors, but I'd think that's
unlikely. So honestly I don't know the cause yet.
llvm-svn: 246621