Modify all read/write calls to allow any system to define MAX_READ_SIZE or MAX_WRITE_SIZE so large reads and writes can be divided up correctly.
<rdar://problem/20471411>
llvm-svn: 234455
atom_collection is basically a wrapper for std::vector. The class
provides begin and end member functions, so that it "hides" the
other member functions provided by std::vector. However, you can
still directly access _atoms member since the member is not
protected.
We cannot simply make the member private because we need that member
when we are constructing atom vectors.
This patch splits atom_collection into two types: std::vector<Atom *>
and AtomRange. When we are constructing atom vectors, we use the
former class. We return instances of the latter class from File
objects so that callers cannot add or remove atoms from the lists.
std::vector<Atom *> is automatically converted to AtomRange.
llvm-svn: 234450
This hooks up the /fp options as aliases for -f[no-]fast-math and
-f[no]-trapping-math. It probably doesn't match cl.exe's behaviour
completely (e.g. LLVM is currently never as precise as /fp:precise),
but it's close enough.
Differential revision: http://reviews.llvm.org/D8909
llvm-svn: 234449
_CxxFrameHandler3 calls terminate if a cleanup action throws, regardless
of what bits you put in the xdata tables. There's no need to model this
in the IR, since we just have to take it out later.
llvm-svn: 234448
The test should be fixed. It was failing in NDEBUG builds due to a
missing '*' character in a regex. In asserts builds, the pattern matched
a single digit value, which became a double digit value in NDEBUG
builds. Go figure.
This reverts commit r234261.
llvm-svn: 234447
The input to compileOptimized is already optimized and internalized, so remove
internalize pass from compileOptimized.
rdar://20227235
llvm-svn: 234446
Summary:
If a struct type S has a member T that has a member that is a function that
returns a typedef of S* the respective field would be duplicated, which caused
an assert down the line in RecordLayoutBuilder. This patch adds a check that
removes the possibility of trying to resolve the same type twice within the
same callstack.
This commit also adds unit tests for these failures.
Fixes https://llvm.org/bugs/show_bug.cgi?id=20486.
Patch by Cristian Hancila.
Test Plan: Run unit tests.
Reviewers: clayborg spyffe
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D8561
llvm-svn: 234441
Summary:
E.g., if thread 1 hits a breakpoint, then a `thread info` on thread 2 will cause
a segfault, since thread 2 will have no stop info (intended behavior?).
Reviewers: kubabrecka, clayborg
Reviewed By: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D8905
llvm-svn: 234437
The bug manifests when there are two loads and two stores chained as follows in
a DAG,
(ld v3f32) -> (st f32) -> (ld v3f32) -> (st f32)
and the stores' values are extracted from the preceding vector loads.
MergeConsecutiveStores would replace the first store in the chain with the
merged vector store, which would create a cycle between the merged store node
and the last load node that appears in the chain.
This commits fixes the bug by replacing the last store in the chain instead.
rdar://problem/20275084
Differential Revision: http://reviews.llvm.org/D8849
llvm-svn: 234430
r234262 changed some code in DIBuilderBindings.cpp to use the unwrap function
to unwrap debug metadata. The problem with this is that unwrap asserts that
its argument is non-null, which is not what we want in a number of places
in DIBuilder where the argument is optional. This change makes certain
arguments optional by adding null checks in places where it is required,
fixing the llgo build.
llvm-svn: 234428
The code uses a priority queue and a worklist, which share the same
visited set, but the visited set is only updated when inserting into
the priority queue. Instead, switch to using separate visited sets
for the priority queue and worklist.
llvm-svn: 234425
(Re-apply r234361 with a fix and a testcase for PR23157)
Both run-time pointer checking and the dependence analysis are capable
of dealing with uniform addresses. I.e. it's really just an orthogonal
property of the loop that the analysis computes.
Run-time pointer checking will only try to reason about SCEVAddRec
pointers or else gives up. If the uniform pointer turns out the be a
SCEVAddRec in an outer loop, the run-time checks generated will be
correct (start and end bounds would be equal).
In case of the dependence analysis, we work again with SCEVs. When
compared against a loop-dependent address of the same underlying object,
the difference of the two SCEVs won't be constant. This will result in
returning an Unknown dependence for the pair.
When compared against another uniform access, the difference would be
constant and we should return the right type of dependence
(forward/backward/etc).
The changes also adds support to query this property of the loop and
modify the vectorizer to use this.
Patch by Ashutosh Nema!
llvm-svn: 234424
Because -menable-no-nans causes fcmp conditions to be rewritten
without 'o' or 'u' the recognition code in needs to cope. Also
extended it to handle 'le' and 'ge.
Differential Revision: http://reviews.llvm.org/D8725
llvm-svn: 234421
Summary:
Even though there is no 2nd register operand in the "lw/sw $8, symbol" case, we still try to find one,
and we end up with $0, which makes us generate an unnecessary "addu $8, $8, $0" (a.k.a. "move $8, $8").
We can avoid this by checking if the 2nd register operand is different from $0, before generating the addu.
Reviewers: dsanders
Reviewed By: dsanders
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D8055
llvm-svn: 234406
Rafael Espindola