Simply loading or storing the frame pointer is not sufficient for
Windows targets. Instead, create a synthetic frame object that we will
lower later. References to this synthetic object will be replaced with
the correct reference to the frame address.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228748 91177308-0d34-0410-b5e6-96231b3b80d8
This implements DebugInfoPDB when the DIA SDK is present on the system.
Specifically, this means that the following conditions are met:
1) You are building on Windows.
2) You are building with MSVC.
3) Visual Studio did not corrupt the installation of DIA due to a
known issue with side-by-side installations of VS2012 and VS2013.
If all of these conditions are true, you will be able to pass a value
of PDB_Reader::DIA to PDB::createPdbReader().
There are no tests for this yet, as any test will be in the form of a
lit test which tests the llvm-pdbdump.exe, which still needs to be
rewritten in terms of this library.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228747 91177308-0d34-0410-b5e6-96231b3b80d8
Unless we meet an insertvalue on a path from some value to a return, that value
will be live if *any* of the return's components are live, so all of those
components must be added to the MaybeLiveUses.
Previously we were deleting arguments if sub-value 0 turned out to be dead.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228731 91177308-0d34-0410-b5e6-96231b3b80d8
Add new API for converting temporaries that may self-reference.
Self-referencing nodes are not allowed to be uniqued, so sending them
into `replaceWithUniqued()` is dangerous (and this commit adds
assertions that prevent it).
`replaceWithPermanent()` has similar semantics to `get()` followed by
calls to `replaceOperandWith()`. In particular, if there's a
self-reference, it returns a distinct node; otherwise, it returns a
uniqued one. Like `replaceWithUniqued()` and `replaceWithDistinct()`
(well, it calls out to them) it mutates the temporary node in place if
possible, only calling `replaceAllUsesWith()` on a uniquing collision.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228726 91177308-0d34-0410-b5e6-96231b3b80d8
See full discussion in http://reviews.llvm.org/D7491.
We now hide the add-immediate and call instructions together in a
separate pseudo-op, which is tagged to define GPR3 and clobber the
call-killed registers. The PPCTLSDynamicCall pass prior to RA now
expands this op into the two separate addi and call ops, with explicit
definitions of GPR3 on both instructions, and explicit clobbers on the
call instruction. The pass is now marked as requiring and preserving
the LiveIntervals and SlotIndexes analyses, and fixes these up after
the replacement sequences are introduced.
Self-hosting has been verified on LE P8 and BE P7 with various
optimization levels, etc. It has also been verified with the
--no-tls-optimize flag workaround removed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228725 91177308-0d34-0410-b5e6-96231b3b80d8
Some old assembly code uses the cntlz alias for cntlzw, binutils supports this,
and we should too. Fixes PR22519.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228719 91177308-0d34-0410-b5e6-96231b3b80d8
Background: When handling underlying objects for a store, the vector
of previous mem uses, mapped to the same Value, is afterwards cleared
(regardless of ThisMayAlias). This means that during handling of the
next store using the same Value, adjustChainDeps() must be called,
otherwise a dependency might be missed.
For example, three spill/reload (NonAliasing) memory accesses using
the same Value 'a', with different offsets:
SU(2): store @a
SU(1): store @a, Offset:1
SU(0): load @a
In this case we have:
* SU(1) does not need a dep against SU(0). Therefore,SU(0) ends up in
RejectMemNodes and is removed from the mem-uses list (AliasMemUses
or NonAliasMemUses), as this list is cleared.
* SU(2) needs a dep against SU(0). Therefore, SU(2) must check
RejectMemNodes by calling adjustChainDeps().
Previously, for store SUs, adjustChainDeps() was only called if
MayAlias was true, missing the S(2) to S(0) dependency in the case
above. The fix is to always call adjustChainDeps(), regardless of
MayAlias, since this applies both for AliasMemUses and
NonAliasMemUses.
No testcase found for any in-tree target.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228686 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds the complete AMD Bulldozer XOP instruction set to the memory folding pattern tables for stack folding, etc.
Note: Many of the XOP instructions have multiple table entries as it can fold loads from different sources.
Differential Revision: http://reviews.llvm.org/D7484
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228685 91177308-0d34-0410-b5e6-96231b3b80d8
This patch teaches X86FastISel how to select AVX instructions for scalar
float/double convert operations.
Before this patch, X86FastISel always selected legacy SSE instructions
for FPExt (from float to double) and FPTrunc (from double to float).
For example:
\code
define double @foo(float %f) {
%conv = fpext float %f to double
ret double %conv
}
\end code
Before (with -mattr=+avx -fast-isel) X86FastIsel selected a CVTSS2SDrr which is
legacy SSE:
cvtss2sd %xmm0, %xmm0
With this patch, X86FastIsel selects a VCVTSS2SDrr instead:
vcvtss2sd %xmm0, %xmm0, %xmm0
Added test fast-isel-fptrunc-fpext.ll to check both the register-register and
the register-memory float/double conversion variants.
Differential Revision: http://reviews.llvm.org/D7438
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228682 91177308-0d34-0410-b5e6-96231b3b80d8
This commit isn't using the correct context, and is transfoming calls
that are operands to loads rather than calls that are operands to an
icmp feeding into an assume. I've replied on the original review thread
with a very reduced test case and some thoughts on how to rework this.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228677 91177308-0d34-0410-b5e6-96231b3b80d8
Since header files are not compilation units, CMake does not require
you to specify them in the CMakeLists.txt file. As a result, unless a
header file is explicitly added, CMake won't know about it, and when
generating IDE-based projects, CMake won't put the header files into
the IDE project. LLVM currently tries to deal with this in two ways:
1) It looks for all .h files that are in the project directory, and
adds those.
2) llvm_add_library() understands the ADDITIONAL_HEADERS argument,
which allows one to list an arbitrary list of headers.
This patch takes things one step further. It adds the ability for
llvm_add_library() to take an ADDITIONAL_HEADER_DIRS argument, which
will specify a list of folders which CMake will glob for header files.
Furthermore, it will glob not only for .h files, but also for .inc
files.
Included in this CL is an update to one of the existing users of
ADDITIONAL_HEADERS to use this new argument instead, to serve as an
illustration of how this cleans up the CMake.
The big advantage of this new approach is that until now, there was no
way for the IDE projects to locate the header files that are in the
include tree. In other words, if you are in, for example,
lib/DebugInfo/DWARF, the corresponding includes for this project will
be located under include/llvm/DebugInfo/DWARF. Now, in the
CMakeLists.txt for lib/DebugInfo/DWARF, you can simply write:
ADDITIONAL_HEADER_DIRS
../../include/llvm/DebugInfo/DWARF
as an argument to llvm_add_library(), and all header files will get
added to the IDE project.
Differential Revision: http://reviews.llvm.org/D7460
Reviewed By: Chris Bieneman
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228670 91177308-0d34-0410-b5e6-96231b3b80d8
nodes when folding bitcasts of constants.
We can't fold things and then check after-the-fact whether it was legal.
Once we have formed the DAG node, arbitrary other nodes may have been
collapsed to it. There is no easy way to go back. Instead, we need to
test for the specific folding cases we're interested in and ensure those
are legal first.
This could in theory make this less powerful for bitcasting from an
integer to some vector type, but AFAICT, that can't actually happen in
the SDAG so its fine. Now, we *only* whitelist specific int->fp and
fp->int bitcasts for post-legalization folding. I've added the test case
from the PR.
(Also as a note, this does not appear to be in 3.6, no backport needed)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228656 91177308-0d34-0410-b5e6-96231b3b80d8
I noticed this fields were never used in r228607, but I neglected to
propagate that into `MDTemplateParameter` until now. This really should
have been done before commit in r228640; sorry for the churn.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228652 91177308-0d34-0410-b5e6-96231b3b80d8
Win64 has specific contraints on what valid prologues and epilogues look
like. This constraint is born from the flexibility and descriptiveness
of Win64's unwind opcodes.
Prologues previously emitted by LLVM could not be represented by the
unwind opcodes, preventing operations powered by stack unwinding to
successfully work.
Differential Revision: http://reviews.llvm.org/D7520
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228641 91177308-0d34-0410-b5e6-96231b3b80d8
Add specialized debug info metadata nodes that match the `DIDescriptor`
wrappers (used by `DIBuilder`) closely. Assembly and bitcode support to
follow soon (it'll mostly just be obvious), but this sketches in today's
schema. This is the first big commit (well, the only *big* one aside
from the testcase changes that'll come when I move this into place) for
PR22464.
I've marked a bunch of obvious changes as `TODO`s in the source; I plan
to make those changes promptly after this hierarchy is moved underneath
`DIDescriptor`, but for now I'm aiming mostly to match the status quo.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228640 91177308-0d34-0410-b5e6-96231b3b80d8
I realized that my early fix for this was overly complicated. Rather than scatter checks around in a bunch of places, just exit early when we visit the poll function itself.
Thinking about it a bit, the whole inlining mechanism used with gc.safepoint_poll could probably be cleaned up a bit. Originally, poll insertion was fused with gc relocation rewriting. It might be worth going back to see if we can simplify the chain of events now that these two are seperated. As one thought, maybe it makes sense to rewrite calls inside the helper function before inlining it to the many callers. This would require us to visit the poll function before any other functions though..
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228634 91177308-0d34-0410-b5e6-96231b3b80d8
for any padding introduced by SROA. In particular, do not emit debug info
for an alloca that represents only the padding introduced by a previous
iteration.
Fixes PR22495.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228632 91177308-0d34-0410-b5e6-96231b3b80d8
intermediate representation. This
- increases consistency by using the same granularity everywhere
- allows for pieces < 1 byte
- DW_OP_piece didn't actually allow storing an offset.
Part of PR22495.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228631 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
It's important that our users immediately know what gc.safepoint_poll
is. Also fix the style of the declaration of CreateGCStatepoint, in
preparation for another change that will wrap it.
Reviewers: reames
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D7517
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228626 91177308-0d34-0410-b5e6-96231b3b80d8
Remove handling for DW_TAG_constant. We started producing it in
r110656, but reverted that in r110876 without dropping the support.
Finish the job.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228623 91177308-0d34-0410-b5e6-96231b3b80d8
`DIExpression` deals with `uint64_t`, so it doesn't make sense that
`createExpression()` is created from `int64_t`. Switch to `uint64_t` to
unify them.
I've temporarily left in the `int64_t` version, which forwards to the
`uint64_t` version. I'll delete it once I've updated the callers.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228619 91177308-0d34-0410-b5e6-96231b3b80d8
This is just adding really simple tests which should have been part of the original submission. When doing so, I discovered that I'd mistakenly removed required pieces when preparing the patch for upstream submission. I fixed two such bugs in this submission.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228610 91177308-0d34-0410-b5e6-96231b3b80d8
