| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
| |
It's fishy to be changing the `std::vector<>` owned by the iterator, and
no one actual does it, so I'm going to remove the ability in a
subsequent commit. First, update the users.
<rdar://problem/14292693>
llvm-svn: 207252
|
| |
|
|
|
|
|
|
| |
check for"
This reverts commit 207235 to investigate msan buildbot breakage.
llvm-svn: 207250
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test Plan:
Run test suite to make sure there is no regression.
https://dmz-portal.mips.com/bb/builders/LLVM%20with%2064bit%20and%20delay%20slot%20optimizer%20and%20direct%20object%20emitter/builds/626
Reviewers: dsanders
Reviewed By: dsanders
Differential Revision: http://reviews.llvm.org/D3497
llvm-svn: 207247
|
| |
|
|
|
|
|
|
| |
This intrinsic is no longer needed with the new @llvm.arm.hint(i32) intrinsic
which provides a generic, extensible manner for adding hint instructions. This
functionality can now be represented as @llvm.arm.hint(i32 5).
llvm-svn: 207246
|
| |
|
|
|
|
|
|
|
|
|
| |
override the default cold threshold.
When we use command line argument to set the inline threshold, the default
cold threshold will not be used. This is in line with how we use
OptSizeThreshold. When we want a higher threshold for all functions, we
do not have to set both inline threshold and cold threshold.
llvm-svn: 207245
|
| |
|
|
|
|
| |
non-null DIE by reference to DbgVariable::setDIE
llvm-svn: 207244
|
| |
|
|
|
|
|
|
|
| |
Introduce the llvm.arm.hint(i32) intrinsic that can be used to inject hints into
the instruction stream. This is particularly useful for generating IR from a
compiler where the user may inject an intrinsic (e.g. __yield). These are then
pattern substituted into the correct instruction which already existed.
llvm-svn: 207242
|
| |
|
|
|
|
|
|
|
|
| |
Debug info: Let dbg.values inserted by LowerDbgDeclare inherit the location
of the dbg.value. This gets rid of tons of redundant variable DIEs in
subscopes.
rdar://problem/14874886, rdar://problem/16679936
llvm-svn: 207236
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
AllocaInst that was missing in one location.
Debug info for optimized code: Support variables that are on the stack and
described by DBG_VALUEs during their lifetime.
Previously, when a variable was at a FrameIndex for any part of its
lifetime, this would shadow all other DBG_VALUEs and only a single
fbreg location would be emitted, which in fact is only valid for a small
range and not the entire lexical scope of the variable. The included
dbg-value-const-byref testcase demonstrates this.
This patch fixes this by
Local
- emitting dbg.value intrinsics for allocas that are passed by reference
- dropping all dbg.declares (they are now fully lowered to dbg.values)
SelectionDAG
- renamed constructors for SDDbgValue for better readability.
- fix UserValue::match() to handle indirect values correctly
- not inserting an MMI table entries for dbg.values that describe allocas.
- lowering dbg.values that describe allocas into *indirect* DBG_VALUEs.
CodeGenPrepare
- leaving dbg.values for an alloca were they are (see comment)
Other
- regenerated/updated instcombine.ll testcase and included source
rdar://problem/16679879
http://reviews.llvm.org/D3374
llvm-svn: 207235
|
| |
|
|
|
|
|
|
|
|
|
|
| |
through the GOT
There's no need for local symbols to go through the GOT, in fact it seems GNU ld is not even emitting GOT entries for local symbols and will error out when trying to resolve a GOT relocation for a local symbol.
This bug triggers when bootstrapping clang on AArch64 Linux with -fPIC and the ARM64 backend. The AArch64 backend is not affected.
With this commit it's now possible to bootstrap clang on AArch64 Linux with the ARM64 backend (-fPIC, -O3).
llvm-svn: 207226
|
| |
|
|
| |
llvm-svn: 207222
|
| |
|
|
|
|
|
|
| |
Also an unused variable, so double bonus!
This should deal with PR19548.
llvm-svn: 207221
|
| |
|
|
| |
llvm-svn: 207219
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SCCMap to test for nodes that have been re-added to the root SCC rather
than a set vector. We already have done the SCCMap lookup, we juts need
to test it in two different ways. In turn, do most of the processing of
these nodes as they go into the root SCC rather than lazily. This
simplifies the final loop to just stitch the root SCC into its
children's parent sets. No functionlatiy changed.
However, this makes a few things painfully obvious, which was my intent.
=] There is tons of repeated code introduced here and elsewhere. I'm
splitting the refactoring of that code into helpers from this change so
its clear that this is the change which switches the datastructures used
around, and the other is a pure factoring & deduplication of code
change.
llvm-svn: 207217
|
| |
|
|
|
|
|
|
|
|
| |
no-fp test.
This patch is a supplement of implementing predicate of FP, enabling aarch64 backend
no-fp tests on arm64 target for verification. During this, one bug is exposed and
fixed by this patch.
llvm-svn: 207215
|
| |
|
|
|
|
|
| |
According to the specification, CRC is an optional extension of the
architecture.
llvm-svn: 207214
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
remove the nodes in the SCC from the SCC map entirely prior to the DFS
walk. This allows the SCC map to represent both the state of
not-yet-re-added-to-an-SCC and added-back-to-this-SCC independently. The
first is being missing from the SCC map, the second is mapping back to
'this'. In a subsequent commit, I'm going to use this property to
simplify the new node list for this SCC.
In theory, I think this also makes the contract for orphaning a node
from the graph slightly less confusing. Now it is also orphaned from the
SCC graph. Still, this isn't quite right either, and so I'm not adding
test cases here. I'll add test cases for the behavior of orphaning nodes
when the code *actually* supports it. The change here is mostly
incidental, my goal is simplifying the algorithm.
llvm-svn: 207213
|
| |
|
|
|
|
|
|
|
| |
child from the worklist, wait until we actually need to pop another
element off of the worklist and skip over any that were already visited
by the DFS. This also enables swapping the nodes of the SCC into the
worklist. No functionality changed.
llvm-svn: 207212
|
| |
|
|
|
|
|
|
|
| |
thing, just mucking up the code. I feel bad that I even wrote this loop.
Very sorry. The diff is huge because of the indent change, but I promise
all this is doing is realizing that the outer two loops were actually
the exact same loops, and we didn't need two of them.
llvm-svn: 207202
|
| |
|
|
|
|
|
|
|
| |
factored into a more reasonable form, replace the tail call with
a simple outer-loop continuation. It's sad that C++ makes this so
awkward to write, but it seems more direct and clear than the tail call
at this point.
llvm-svn: 207201
|
| |
|
|
|
|
|
|
|
|
|
| |
Change the object streamer selection to a switch from a series of if conditions.
Rather than defaulting to ELF, require that an ELF format is requested. The
Windows/!ELF is maintained as MachO would have been selected first and will
still provide a MachO format. Add an assertion that if COFF is requested that
the target platform is Windows as only WinCOFF object emission is currently
supported.
llvm-svn: 207200
|
| |
|
|
|
|
| |
Code review feedback from Paul Robinson on r207022
llvm-svn: 207198
|
| |
|
|
| |
llvm-svn: 207197
|
| |
|
|
| |
llvm-svn: 207196
|
| |
|
|
|
|
|
|
|
|
| |
Remove the concepts of "forward" and "general" mass distributions, which
was wrong. The split might have made sense in an early version of the
algorithm, but it's definitely wrong now.
<rdar://problem/14292693>
llvm-svn: 207195
|
| |
|
|
|
|
| |
<rdar://problem/14292693>
llvm-svn: 207194
|
| |
|
|
|
|
| |
<rdar://problem/14292693>
llvm-svn: 207191
|
| |
|
|
|
|
|
|
|
|
|
| |
Rather than scaling loop headers and then scaling all the loop members
by the header frequency, scale `LoopData::Scale` itself, and scale the
loop members by it. It's much more obvious what's going on this way,
and doesn't cost any extra multiplies.
<rdar://problem/14292693>
llvm-svn: 207189
|
| |
|
|
|
|
| |
<rdar://problem/14292693>
llvm-svn: 207188
|
| |
|
|
|
|
| |
<rdar://problem/14292693>
llvm-svn: 207187
|
| |
|
|
|
|
|
|
| |
When unwrapping loops, just visit the loops rather than all nodes.
<rdar://problem/14292693>
llvm-svn: 207186
|
| |
|
|
|
|
| |
<rdar://problem/14292693>
llvm-svn: 207185
|
| |
|
|
|
|
|
|
|
| |
Make `getPackagedNode()` a member function of
`BlockFrequencyInfoImplBase` so that it's available for templated code.
<rdar://problem/14292693>
llvm-svn: 207183
|
| |
|
|
|
|
| |
<rdar://problem/14292693>
llvm-svn: 207182
|
| |
|
|
|
|
| |
<rdar://problem/14292693>
llvm-svn: 207181
|
| |
|
|
|
|
|
|
| |
Instead of passing around loop headers, pass around `LoopData` directly.
<rdar://problem/14292693>
llvm-svn: 207179
|
| |
|
|
|
|
|
|
|
|
|
|
| |
As pointed out by David Blaikie in code review, a `std::list<T>` is
simpler than a `std::vector<std::unique_ptr<T>>`. Another option is a
`std::deque<T>` (which allocates in chunks), but I'd like to leave open
the option of inserting in the middle of the sequence for handling
irreducible control flow on the fly.
<rdar://problem/14292693>
llvm-svn: 207177
|
| |
|
|
|
|
| |
This patch adds support for vectorization of bit intrinsics such as bswap,ctpop,ctlz,cttz.
llvm-svn: 207174
|
| |
|
|
| |
llvm-svn: 207172
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
iteration.
When fixing the symbols in each compressed section we were iterating
over all symbols for each compressed section. In extreme cases this
could snowball severely (5min uncompressed -> 35min compressed) due to
iterating over all symbols for each compressed section (large numbers of
compressed sections can be generated by DWARF type units).
To address this, build a map of the symbols in each section ahead of
time, and access that map if a section is being compressed. This brings
compile time for the aforementioned example down to ~6 minutes.
llvm-svn: 207167
|
| |
|
|
|
|
|
|
| |
check for"
Typo in testcase.
llvm-svn: 207166
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
AllocaInst that was missing in one location.
Debug info for optimized code: Support variables that are on the stack and
described by DBG_VALUEs during their lifetime.
Previously, when a variable was at a FrameIndex for any part of its
lifetime, this would shadow all other DBG_VALUEs and only a single
fbreg location would be emitted, which in fact is only valid for a small
range and not the entire lexical scope of the variable. The included
dbg-value-const-byref testcase demonstrates this.
This patch fixes this by
Local
- emitting dbg.value intrinsics for allocas that are passed by reference
- dropping all dbg.declares (they are now fully lowered to dbg.values)
SelectionDAG
- renamed constructors for SDDbgValue for better readability.
- fix UserValue::match() to handle indirect values correctly
- not inserting an MMI table entries for dbg.values that describe allocas.
- lowering dbg.values that describe allocas into *indirect* DBG_VALUEs.
CodeGenPrepare
- leaving dbg.values for an alloca were they are (see comment)
Other
- regenerated/updated instcombine.ll testcase and included source
rdar://problem/16679879
http://reviews.llvm.org/D3374
llvm-svn: 207165
|
| |
|
|
|
|
|
|
| |
stack and"
This reverts commit 207130 for buildbot breakage.
llvm-svn: 207162
|
| |
|
|
|
|
|
|
| |
location"
This reverts commit 207130 for buildbot breakage.
llvm-svn: 207159
|
| |
|
|
| |
llvm-svn: 207156
|
| |
|
|
|
|
| |
section. Remove the former.
llvm-svn: 207153
|
| |
|
|
| |
llvm-svn: 207151
|
| |
|
|
|
|
|
| |
condition into an obviously infinite loop with an assert about the
degenerate condition. No functionality changed.
llvm-svn: 207147
|
| |
|
|
|
|
| |
Should unbreak MultiSource/Benchmarks/mediabench/g721/g721encode/encode.
llvm-svn: 207145
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This is similar to the 'tail' marker, except that it guarantees that
tail call optimization will occur. It also comes with convervative IR
verification rules that ensure that tail call optimization is possible.
Reviewers: nicholas
Differential Revision: http://llvm-reviews.chandlerc.com/D3240
llvm-svn: 207143
|