We would infinite loop because we created a shufflevector that was wider than
needed and then failed to combine that with the insertelement. When subsequently
visiting the extractelement from that shuffle, we see that it's unnecessary,
delete it, and trigger another visit to the insertelement.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@259236 91177308-0d34-0410-b5e6-96231b3b80d8
This support is _very_ rudimentary, just enough to get some basic data
into the CodeView debug section.
Left to do is:
- Use the combined opcodes to save space.
- Do something about code offsets.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@259230 91177308-0d34-0410-b5e6-96231b3b80d8
The basic optimisation was to convert (mul $LHS, $complex_constant) into
roughly "(shl (mul $LHS, $simple_constant), $simple_amt)" when it was expected
to be cheaper. The original logic checks that the mul only has one use (since
we're mangling $complex_constant), but when used in even more complex
addressing modes there may be an outer addition that can pick up the wrong
value too.
I *think* the ARM addressing-mode problem is actually unreachable at the
moment, but that depends on complex assessments of the profitability of
pre-increment addressing modes so I've put a real check in there instead of an
assertion.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@259228 91177308-0d34-0410-b5e6-96231b3b80d8
Add support for frame pointer use in prolog/epilog.
Supports dynamic allocas but not yet over-aligned locals.
Target-independend CG generates SP updates, but we still need to write
back the SP value to memory when necessary.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@259220 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
There are three parts to inlined call frames:
1. The inlinee line subsection
2. The inline site symbol record
3. The function ids referenced by both
This change starts by emitting function ids (3) for all subprograms and
emitting the base inline site symbol record (2). The actual line numbers
in (2) use an encoded format that will come next, along with the inlinee
line subsection.
Reviewers: majnemer
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D16333
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@259217 91177308-0d34-0410-b5e6-96231b3b80d8
- Locally declare struct, and call it BaseDerivedPair
- Use a lambda to compare, instead of a singleton with uninitialized
fields
- Add a constructor to BaseDerivedPair and use SmallVector::emplace_back
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@259208 91177308-0d34-0410-b5e6-96231b3b80d8
The buildSchedGraph() was in need of reworking as the AA features had been
added on top of earlier code. It was very difficult to understand, and buggy.
There had been found cases where scheduling dependencies had actually been
missed (see r228686).
AliasChain, RejectMemNodes, adjustChainDeps() and iterateChainSucc() have
been removed. There are instead now just the four maps from Value to SUs, which
have been renamed to Stores, Loads, NonAliasStores and NonAliasLoads.
An unknown store used to become the AliasChain, but now becomes a store mapped
to 'unknownValue' (in Stores). What used to be PendingLoads is instead the
list of SUs mapped to 'unknownValue' in Loads.
RejectMemNodes and adjustChainDeps() used to be a safety-net for everything.
The SU maps were sometimes cleared and SUs were put in RejectMemNodes, where
adjustChainDeps() would look. Instead of this, a more straight forward approach
is used in maintaining the SU maps without clearing them and simply letting
them grow over time. Instead of the cutt-off in adjustChainDeps() search, a
reduction of maps will be done if needed (see below).
Each SUnit either becomes the BarrierChain, or is put into one of the maps. For
each SUnit encountered, all the information about previous ones are still
available until a new BarrierChain is set, at which point the maps are cleared.
For huge regions, the algorithm becomes slow, therefore the maps will get
reduced at a threshold (current default is 1000 nodes), by a fraction (default 1/2).
These values can be tuned by use of CL options in case some test case shows that
they need to be changed (-dag-maps-huge-region and -dag-maps-reduction-size).
There has not been any considerable change observed in output quality or compile
time. There may now be more DAG edges inserted than before (i.e. if A->B->C,
then A->C is not needed). However, in a comparison run there were fewer total
calls to AA, and a somewhat improved compile time, which means this seems to
be not a problem.
http://reviews.llvm.org/D8705
Reviewers: Hal Finkel, Andy Trick.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@259201 91177308-0d34-0410-b5e6-96231b3b80d8
Also removed a few redundant `else`s.
Bug was found by a test I wrote for MemorySSA (in review at
http://reviews.llvm.org/D7864; shiny update coming soon). So, assuming
that lands at some point, this should be covered by that. If anyone
feels this deserves its own explicit test case, please let me know.
I'll write one.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@259179 91177308-0d34-0410-b5e6-96231b3b80d8
check that the sign extended constant fits into 16-bits if we want a
zero extended value, otherwise go ahead and put it together piecemeal.
Fixes PR26356.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@259177 91177308-0d34-0410-b5e6-96231b3b80d8
This patch enables llvm-bcanalyzer to print the bitcode wrapper header
if the file has one, which is needed to test the changes made in
r258627 (bitcode-wrapper-header-armv7m.ll is the test case for r258627).
Differential Revision: http://reviews.llvm.org/D16642
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@259162 91177308-0d34-0410-b5e6-96231b3b80d8
Our cleanups do not support true lexical nesting of funclets which
obviates the need to perform state stores.
This fixes PR26361.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@259161 91177308-0d34-0410-b5e6-96231b3b80d8
I don't seem to see these locally, maybe just need to update my
compiler, or we haven't turned them on for LLVM's build and we should...
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@259146 91177308-0d34-0410-b5e6-96231b3b80d8
Just adding an assert which makes invariants between AnalyzeLoadsFromClobberingLoads and GetLoadValueForLoad slightly more clear.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@259145 91177308-0d34-0410-b5e6-96231b3b80d8
Since we only have pair - not single - nontemporal store instructions,
we have to extract the high part into a separate register to be able
to use them.
When the initial nontemporal codegen support was added, I wrote the
extract using the nonsensical UBFX [0,32[.
Use the correct LSR form instead.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@259134 91177308-0d34-0410-b5e6-96231b3b80d8
The full diff for the test directory may be hard to read because of the
filename clash; so here's all that happened as far as the tests are
concerned:
```
cd test/Transforms/RewriteStatepointsForGC
git rm *ll
git mv deopt-bundles/* ./
rmdir deopt-bundles
find . -name '*.ll' | xargs gsed -i 's/-rs4gc-use-deopt-bundles //g'
```
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@259129 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r259117.
The LineInfo constructor is defined in the codeview library and we have
to link against it now. Doing that isn't trivial, so reverting for now.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@259126 91177308-0d34-0410-b5e6-96231b3b80d8
two-invokes-one-landingpad.ll was only moved (and not "ported"), but
having everything in the `deopt-bundles` directory will make later
changes more obvious.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@259125 91177308-0d34-0410-b5e6-96231b3b80d8
Prior to r259115 this was coming via LTOModule.h and MCContext.h.
Apparently this target is not built by 'check'. =(
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@259124 91177308-0d34-0410-b5e6-96231b3b80d8
When the caller has optsize attribute, we reduce the inlinining threshold
to OptSizeThreshold (=75) if it is not already lower than that. We don't do
the same for minsize and I suspect it was not intentional. This also addresses
a FIXME regarding checking optsize attribute explicitly instead of using the
right wrapper.
Differential Revision: http://reviews.llvm.org/D16493
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@259120 91177308-0d34-0410-b5e6-96231b3b80d8
Adds a new family of .cv_* directives to LLVM's variant of GAS syntax:
- .cv_file: Similar to DWARF .file directives
- .cv_loc: Similar to the DWARF .loc directive, but starts with a
function id. CodeView line tables are emitted by function instead of
by compilation unit, so we needed an extra field to communicate this.
Rather than overloading the .loc direction further, we decided it was
better to have our own directive.
- .cv_stringtable: Emits the codeview string table at the current
position. Currently this just contains the filenames as
null-terminated strings.
- .cv_filechecksums: Emits the file checksum table for all files used
with .cv_file so far. There is currently no support for emitting
actual checksums, just filenames.
This moves the line table emission code down into the assembler. This
is in preparation for implementing the inlined call site line table
format. The inline line table format encoding algorithm requires knowing
the absolute code offsets, so it must run after the assembler has laid
out the code.
David Majnemer collaborated on this patch.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@259117 91177308-0d34-0410-b5e6-96231b3b80d8
