| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
Eli discovered that __noop's sema behavior also needs some love. I filed
PR14081 for that and intend to improve it.
llvm-svn: 165886
|
| |
|
|
| |
llvm-svn: 165885
|
| |
|
|
|
|
| |
when calling overflow to correctly handle negative signed character types. This fixes http://llvm.org/bugs/show_bug.cgi?id=14074.
llvm-svn: 165884
|
| |
|
|
|
|
| |
failing dynamic_casts that a few applications are doing on the type_info hierarchy.
llvm-svn: 165883
|
| |
|
|
|
|
| |
adjust the inclusion of quick_exit.
llvm-svn: 165882
|
| |
|
|
| |
llvm-svn: 165881
|
| |
|
|
|
|
| |
nopl instead of nopw.
llvm-svn: 165880
|
| |
|
|
| |
llvm-svn: 165879
|
| |
|
|
| |
llvm-svn: 165878
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The new coalescer can merge a dead def into an unused lane of an
otherwise live vector register.
Clear the <dead> flag when that happens since the flag refers to the
full virtual register which is still live after the partial dead def.
This fixes PR14079.
llvm-svn: 165877
|
| |
|
|
| |
llvm-svn: 165876
|
| |
|
|
|
|
|
| |
This patch migrates the strchr and strrchr optimizations from the
simplify-libcalls pass into the instcombine library call simplifier.
llvm-svn: 165875
|
| |
|
|
|
|
|
| |
This patch migrates the strcat and strncat optimizations from the
simplify-libcalls pass into the instcombine library call simplifier.
llvm-svn: 165874
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch implements the new LibCallSimplifier class as outlined in [1].
In addition to providing the new base library simplification infrastructure,
all the fortified library call simplifications were moved over to the new
infrastructure. The rest of the library simplification optimizations will
be moved over with follow up patches.
NOTE: The original fortified library call simplifier located in the
SimplifyFortifiedLibCalls class was not removed because it is still
used by CodeGenPrepare. This class will eventually go away too.
[1] http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-August/052283.html
llvm-svn: 165873
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
It is possible that the live range of the value being pruned loops back
into the kill MBB where the search started. When that happens, make sure
that the beginning of KillMBB is also pruned.
Instead of starting a DFS at KillMBB and skipping the root of the
search, start a DFS at each KillMBB successor, and allow the search to
loop back to KillMBB.
This fixes PR14078.
llvm-svn: 165872
|
| |
|
|
| |
llvm-svn: 165871
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
type coercion code, especially when targetting ARM. Things like [1
x i32] instead of i32 are very common there.
The goal of this logic is to ensure that when we are picking an alloca
type, we look through such wrapper aggregates and across any zero-length
aggregate elements to find the simplest type possible to form a type
partition.
This logic should (generally speaking) rarely fire. It only ends up
kicking in when an alloca is accessed using two different types (for
instance, i32 and float), and the underlying alloca type has wrapper
aggregates around it. I noticed a significant amount of this occurring
looking at stepanov_abstraction generated code for arm, and suspect it
happens elsewhere as well.
Note that this doesn't yet address truly heinous IR productions such as
PR14059 is concerning. Those result in mismatched *sizes* of types in
addition to mismatched access and alloca types.
llvm-svn: 165870
|
| |
|
|
|
|
|
|
|
| |
help the dragonegg builders, and no test case at this point, but this
was one dimly plausible case I spotted by inspection. Hopefully will get
a testcase from those bots soon-ish, and will tidy this up with proper
testing.
llvm-svn: 165869
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
same width.
X86 doesn't have i8 cmovs so isel would emit a branch. Emitting branches at this
level is often not a good idea because it's too late for many optimizations to
kick in. This solution doesn't add any extensions (truncs are free) and tries
to avoid introducing partial register stalls by filtering direct copyfromregs.
I'm seeing a ~10% speedup on reading a random .png file with libpng15 via
graphicsmagick on x86_64/westmere, but YMMV depending on the microarchitecture.
llvm-svn: 165868
|
| |
|
|
| |
llvm-svn: 165867
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This was only used by OSAtomicChecker and makes it more
difficult to update values for expressions that the environment
may look through instead (it's not the same as IgnoreParens).
With this gone, we can have bindExpr bind to the inner
expression that getSVal will find.
Groundwork for <rdar://problem/12137950>
llvm-svn: 165866
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
I believe the removed assert in CheckerManager says it best:
InlineCall is a special hacky callback to allow intrusive
evaluation of the call (which simulates inlining). It is
currently only used by OSAtomicChecker and should go away
at some point.
OSAtomicChecker has gone away; inlineCall can now go away as well!
llvm-svn: 165865
|
| |
|
|
|
|
|
|
|
|
|
|
| |
are single value types, the load and store should be directly based upon
the alloca and then bitcasting can fix the type as needed afterward.
This might in theory improve some of the IR coming out of SROA, but
I don't expect big changes yet and don't have any test cases on hand.
This is really just a cleanup/refactoring patch. The next patch will
cause this code path to be hit a lot more, actually get SROA to promote
more allocas and include several more test cases.
llvm-svn: 165864
|
| |
|
|
|
|
|
|
|
| |
emulating 128-bit arithmetic on 32-bit x86 targets. This should get the
bootstrap back for GCC 4.6 at least.
Suggestions on better ways to do the detection here are welcome...
llvm-svn: 165863
|
| |
|
|
|
|
| |
bit thread ID.
llvm-svn: 165862
|
| |
|
|
|
|
|
|
|
|
|
| |
I added the ability for a process plug-in to implement custom commands. All the lldb_private::Process plug-in has to do is override:
virtual CommandObject *
GetPluginCommandObject();
This object returned should be a multi-word command that vends LLDB commands. There is a sample implementation in ProcessGDBRemote that is hollowed out. It is intended to be used for sending a custom packet, though the body of the command execute function has yet to be implemented!
llvm-svn: 165861
|
| |
|
|
| |
llvm-svn: 165860
|
| |
|
|
| |
llvm-svn: 165859
|
| |
|
|
|
|
|
|
|
|
|
| |
the interface between the front-end and the MC layer when parsing inline
assembly. Unfortunately, this is too deep into the parsing stack. Specifically,
we're unable to handle target-independent assembly (i.e., assembly directives,
labels, etc.). Note the MatchAndEmitInstruction() isn't the correct
abstraction either. I'll be exposing target-independent hooks shortly, so this
is really just a cleanup.
llvm-svn: 165858
|
| |
|
|
|
|
| |
From SBType, we can now get a lldb::BasicType enumeration out of an existing type.
llvm-svn: 165857
|
| |
|
|
| |
llvm-svn: 165856
|
| |
|
|
|
|
| |
while processing relocations.
llvm-svn: 165854
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
local frame causes problem.
For example:
void f(StructToPass s) {
g(&s, sizeof(s));
}
will cause problem with tail-call since part of s is passed via registers and
saved in f's local frame. When g tries to access s, part of s may be corrupted
since f's local frame is popped out before the tail-call.
The current fix is to disable tail-call if getVarArgsRegSaveSize is not 0 for
the caller. This is a conservative approach, if we can prove the address of
s or part of s is not taken and passed to g, it should be okay to perform
tail-call.
rdar://12442472
llvm-svn: 165853
|
| |
|
|
|
|
| |
SBProcess::SetSelectedThreadByID() had a "uint32_t tid" parameter which would truncate 64 bit thread IDs (lldb::tid_t is 64 bit).
llvm-svn: 165852
|
| |
|
|
| |
llvm-svn: 165851
|
| |
|
|
|
|
| |
Patch by Tom Stellard.
llvm-svn: 165850
|
| |
|
|
|
|
| |
Patch by Jeremiah Zanin.
llvm-svn: 165849
|
| |
|
|
|
|
| |
Memory write wasn't working (assert was firing) when writing memory.
llvm-svn: 165848
|
| |
|
|
| |
llvm-svn: 165847
|
| |
|
|
| |
llvm-svn: 165846
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The backend already pattern matches to form VBSL when it can. We may want to
teach it to use the vbsl intrinsics at some point to prevent machine licm from
mucking with this, but using the Expand is completely correct.
http://llvm.org/bugs/show_bug.cgi?id=13831
http://llvm.org/bugs/show_bug.cgi?id=13961
Patch by Peter Couperus <peter.couperus@st.com>.
llvm-svn: 165845
|
| |
|
|
|
|
|
|
|
| |
to or
from a floating-point type where the source value is not in the range of
representable values of the destination type.
llvm-svn: 165844
|
| |
|
|
|
|
|
| |
from a floating-point type where the source value is not in the range of
representable values of the destination type.
llvm-svn: 165843
|
| |
|
|
| |
llvm-svn: 165842
|
| |
|
|
|
|
|
| |
that a DeclRefExpr can never return a null decl. We possibly should
hoist this into getDecl() itself.
llvm-svn: 165841
|
| |
|
|
|
|
| |
invariants using assertions.
llvm-svn: 165840
|
| |
|
|
|
|
| |
the server root.
llvm-svn: 165839
|
| |
|
|
|
|
| |
the number of arguments.
llvm-svn: 165838
|
| |
|
|
|
|
|
| |
add more code that references SourceFile, so removing the dead store
doesn't seem appropriate for the long term.
llvm-svn: 165837
|
| |
|
|
| |
llvm-svn: 165836
|