| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
- input_iterator
- define an operator->
- make constructors private were possible
llvm-svn: 226967
|
|
|
|
|
|
|
| |
Nothing in lib/ should be using llvm::outs() directly. Thread it in
from the caller instead.
llvm-svn: 226961
|
|
|
|
| |
llvm-svn: 226960
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Handle the poor codegen for i64/x86xmm->v2i64 (%mm -> %xmm) moves. Instead of
using stack store/load pair to do the job, use scalar_to_vector directly, which
in the MMX case can use movq2dq. This was the current behavior prior to
improvements for vector legalization of extloads in r213897.
This commit fixes the regression and as a side-effect also remove some
unnecessary shuffles.
In the new attached testcase, we go from:
pshufw $-18, (%rdi), %mm0
movq %mm0, -8(%rsp)
movq -8(%rsp), %xmm0
pshufd $-44, %xmm0, %xmm0
movd %xmm0, %eax
...
To:
pshufw $-18, (%rdi), %mm0
movq2dq %mm0, %xmm0
movd %xmm0, %eax
...
Differential Revision: http://reviews.llvm.org/D7126
rdar://problem/19413324
llvm-svn: 226953
|
|
|
|
| |
llvm-svn: 226952
|
|
|
|
| |
llvm-svn: 226949
|
|
|
|
|
|
|
| |
These constructors were causing trouble for MSVC and older GCCs. This should
fix more of the build failures from r226940.
llvm-svn: 226946
|
|
|
|
|
|
|
|
|
|
|
| |
We used to do this promotion during DAG legalization, but this
caused an infinite loop in ExpandUnalignedLoad() because it assumed
that i64 loads were legal if i64 was a legal type.
It also seems better to report i64 loads as legal, since they actually
are and we were just promoting them to simplify our tablegen files.
llvm-svn: 226945
|
|
|
|
| |
llvm-svn: 226943
|
|
|
|
| |
llvm-svn: 226942
|
|
|
|
|
|
| |
This should fix some of the builder errors from r226940.
llvm-svn: 226941
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds a new set of JIT APIs to LLVM. The aim of these new APIs is to
cleanly support a wider range of JIT use cases in LLVM, and encourage the
development and contribution of re-usable infrastructure for LLVM JIT use-cases.
These APIs are intended to live alongside the MCJIT APIs, and should not affect
existing clients.
Included in this patch:
1) New headers in include/llvm/ExecutionEngine/Orc that provide a set of
components for building JIT infrastructure.
Implementation code for these headers lives in lib/ExecutionEngine/Orc.
2) A prototype re-implementation of MCJIT (OrcMCJITReplacement) built out of the
new components.
3) Minor changes to RTDyldMemoryManager needed to support the new components.
These changes should not impact existing clients.
4) A new flag for lli, -use-orcmcjit, which will cause lli to use the
OrcMCJITReplacement class as its underlying execution engine, rather than
MCJIT itself.
Tests to follow shortly.
Special thanks to Michael Ilseman, Pete Cooper, David Blaikie, Eric Christopher,
Justin Bogner, and Jim Grosbach for extensive feedback and discussion.
llvm-svn: 226940
|
|
|
|
|
|
|
|
| |
DIExpression::Operand, so we can write range-based for loops.
Thanks to David Blaikie for the idea.
llvm-svn: 226939
|
|
|
|
|
|
| |
trivial first commit
llvm-svn: 226935
|
|
|
|
|
|
|
|
|
|
|
|
| |
SimplifyCFG currently does this transformation, but I'm planning to remove that
to allow other passes, such as this one, to exploit the unreachable default.
This patch takes care to keep track of what case values are unreachable even
after the transformation, allowing for more efficient lowering.
Differential Revision: http://reviews.llvm.org/D6697
llvm-svn: 226934
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This mostly reverts commit r222062 and replaces it with a new enum. At
some point this enum will grow at least for other MSVC EH personalities.
Also beefs up the way we were sniffing the personality function.
Previously we would emit the Itanium LSDA despite using
__C_specific_handler.
Reviewers: majnemer
Differential Revision: http://reviews.llvm.org/D6987
llvm-svn: 226920
|
|
|
|
| |
llvm-svn: 226919
|
|
|
|
|
|
| |
in the couple of asserts.
llvm-svn: 226917
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
directive.
Summary:
We used to silently ignore any empty .module's and we used to give an error saying that we found
an "unexpected token at start of statement" when the value of the option wasn't an identifier (e.g. if it was a number).
We now give an error saying that we "expected .module option identifier" in both of those cases.
I also fixed the other tests in mips-abi-bad.s, which all seemed to be broken.
Reviewers: dsanders
Reviewed By: dsanders
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D7095
llvm-svn: 226905
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
_foo:
smull r0, r1, r1, r0
smull r2, r3, r3, r2
adds r0, r2, r0
adc r1, r3, r1
bx lr
to
_foo:
smull r0, r1, r1, r0
smlal r0, r1, r3, r2
bx lr
llvm-svn: 226904
|
|
|
|
|
|
| |
masks and the like make way more sense.
llvm-svn: 226902
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: When trying to constant fold an FMA in the DAG, getNode()
fails to fold the FMA if an operand is not finite. In this case this
patch allows the constant folding if !TLI->hasFloatingPointExceptions()
Reviewers: resistor
Reviewed By: resistor
Subscribers: hfinkel, llvm-commits
Differential Revision: http://reviews.llvm.org/D6912
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 226901
|
|
|
|
| |
llvm-svn: 226897
|
|
|
|
|
|
| |
This lets llvm-mc assemble files produced by gcc.
llvm-svn: 226895
|
|
|
|
| |
llvm-svn: 226888
|
|
|
|
| |
llvm-svn: 226887
|
|
|
|
|
|
|
|
| |
v2: add and enable tests for SI
Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
Reviewed-by: Matt Arsenault <Matthew.Arsenault@amd.com>
llvm-svn: 226881
|
|
|
|
|
|
|
|
|
|
|
|
| |
v2: use getZExtValue
add missing break
codestyle
v3: add few more comments
Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
Reviewed-by: Matt Arsenault <Matthew.Arsenault@amd.com>
llvm-svn: 226880
|
|
|
|
|
|
|
|
|
|
|
| |
optimizations can handle removing the Hi part operations.
The generated code is identical for R600, ~10% icount reduction for SI
v2: rebase
Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
Reviewed-by: Matt Arsenault <Matthew.Arsenault@amd.com>
llvm-svn: 226879
|
|
|
|
|
|
|
| |
Simplify the API to use a `StringRef` directly rather than exposing the
`MDString` bits underneath.
llvm-svn: 226876
|
|
|
|
|
|
|
|
|
| |
These things are potentially used for non-DWARF data (see the discussion
in PR22235), so take the `Dwarf` out of the name. Since the new name
gives fewer clues, update the doxygen to properly describe what they
are.
llvm-svn: 226874
|
|
|
|
|
|
|
|
| |
Minor tweak now that D7042 is complete, we can enable stack folding for (V)MOVDDUP and do proper testing.
Added missing AVX ymm folding patterns and fixed alignment for AVX VMOVSLDUP / VMOVSHDUP.
llvm-svn: 226873
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I had already factored this analysis specifically to enable doing this,
but hadn't actually committed the necessary wiring to get at this from
the new pass manager. This also nicely shows how the separate cache
object can be directly managed by the new pass manager.
This analysis didn't have any direct tests and so I've added a printer
pass and a boring test case. I chose to print the i1 value which is
being assumed rather than the call to llvm.assume as that seems much
more useful for testing... but suggestions on an even better printing
strategy welcome. My main goal was to make sure things actually work. =]
llvm-svn: 226868
|
|
|
|
| |
llvm-svn: 226867
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
During `MDNode::deleteTemporary()`, call `replaceAllUsesWith(nullptr)`
to update all tracking references to `nullptr`.
This fixes PR22280, where inverted destruction order between tracking
references and the temporaries themselves caused a use-after-free in
`LLParser`.
An alternative fix would be to add an assertion that there are no users,
and continue to fix inverted destruction order in clients (like
`LLParser`), but instead I decided to make getting-teardown-right easy.
(If someone disagrees let me know.)
llvm-svn: 226866
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Some parsers need references back to the option they are members of. This is used for handling the argument string as well as by the various pass name parsers for making pass names into flags.
Making parsers that need to refer back to the option have a reference to the option eliminates some of the members of various parsers, and enables further code cleanup.
Reviewers: dexonsmith
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D7131
llvm-svn: 226864
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Specifically, gc.result benefits from this greatly. Instead of:
gc.result.int.*
gc.result.float.*
gc.result.ptr.*
...
We now have a gc.result.* that can specialize to literally any type.
Differential Revision: http://reviews.llvm.org/D7020
llvm-svn: 226857
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit r176827.
Björn Steinbrink pointed out that this didn't actually fix the bug
(PR15555) it was attempting to fix.
With this reverted, we can now remove landingpad cleanups that
immediately resume unwinding, converting the invoke to a call.
llvm-svn: 226850
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a 2nd try at the same optimization as http://reviews.llvm.org/D6698.
That patch was checked in at r224611, but reverted at r225031 because it
caused a failure outside of the regression tests.
The cause of the crash was not recognizing consecutive stores that have mixed
source values (loads and vector element extracts), so this patch adds a check
to bail out if any store value is not coming from a vector element extract.
This patch also refactors the shared logic of the constant source and vector
extracted elements source cases into a helper function.
Differential Revision: http://reviews.llvm.org/D6850
llvm-svn: 226845
|
|
|
|
|
|
|
|
|
|
|
| |
problems when inlining two calls to the same function from the same call site."
The underlying bug has been fixed in r226736 so there's no need to
workaround this anymore.
This reverts commit r220923.
llvm-svn: 226842
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, we're adding a uint64_t describing the current subtarget so
that matching can check whether the specified register is valid.
However, we want to move to a bitset for those bits (x86 has more than
64 of them).
This can't live in a union so it's probably better to do the checks
early (especially as there are only 3 of them).
llvm-svn: 226841
|
|
|
|
|
|
| |
NFC.
llvm-svn: 226836
|
|
|
|
|
|
| |
Addresses review feedback from Duncan.
llvm-svn: 226835
|
|
|
|
|
|
|
|
|
|
|
|
| |
The ELF format is used on Windows by the MCJIT engine. Thus, on Windows, the
ELFObjectWriter can encounter symbols mangled using the MS Visual Studio C++
name mangling. Symbols mangled using the MSVC C++ name mangling can legally
have "@@@" as a substring. The EFLObjectWriter should not interpret the "@@@"
substring as specifying GNU-style symbol versioning. The ELFObjectWriter
therefore check for the MSVC C++ name mangling prefix which is either "?", "@?",
"imp_?" or "imp_?@".
llvm-svn: 226830
|
|
|
|
|
|
| |
unsigned expressions anyway); NFC.
llvm-svn: 226826
|
|
|
|
|
|
|
|
|
|
|
| |
This solves PR22276.
Splats of constants would sometimes produce redundant shuffles, sometimes ridiculously so (see the PR for details). Fold these shuffles into BUILD_VECTORs early on instead.
Differential Revision: http://reviews.llvm.org/D7093
Fixed recommit of r226811.
llvm-svn: 226816
|
|
|
|
|
|
| |
(These vars are only used in assertions)
llvm-svn: 226815
|
|
|
|
| |
llvm-svn: 226814
|
|
|
|
|
|
|
|
|
| |
This solves PR22276.
Splats of constants would sometimes produce redundant shuffles, sometimes ridiculously so (see the PR for details). Fold these shuffles into BUILD_VECTORs early on instead.
Differential Revision: http://reviews.llvm.org/D7093
llvm-svn: 226811
|
|
|
|
| |
llvm-svn: 226809
|