std::strings) rather than StringRefs in JITSymbol get-address lambda.
Capturing a StringRef by-value is still effectively capturing a reference, which
is no good here because the referenced string may be gone by the time the lambda
is being evaluated the original value may be gone. Make sure to capture a
std::string instead.
No test case: This bug doesn't manifest under OrcMCJITReplacement, since it
keeps IR modules (from which the StringRefs are sourced) alive permanently.
llvm-svn: 228676
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
llvm-svn: 228670
This allows all CMake projects, as well as C++ code, to detect if
and when DIA SDK is available for use so that we can enable the
DIA-based PDB reader implementation.
Differential Revision: http://reviews.llvm.org/D7457
Reviewed By: Chandler Carruth
llvm-svn: 228669
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)
llvm-svn: 228656
Summary:
The CMake configuration is explicitely looking for Debug build, all the
other variant disable assertions.
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D7359
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 228653
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.
llvm-svn: 228652
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
llvm-svn: 228641
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.
llvm-svn: 228640
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..
llvm-svn: 228634
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.
llvm-svn: 228632
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.
llvm-svn: 228631
I just realized that the specialized metadata node patch I'm about to
commit won't compile on old compilers. Bump `hash_combine()`'s support
for non-variadic templates to 18 (I tested this by reversing the logic
in the #ifdef).
llvm-svn: 228629
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
llvm-svn: 228626
Remove handling for DW_TAG_constant. We started producing it in
r110656, but reverted that in r110876 without dropping the support.
Finish the job.
llvm-svn: 228623
`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.
llvm-svn: 228619
These tests the two optimizations for backedge insertion currently implemented and the split backedge flag which is currently off by default.
llvm-svn: 228617
Without a valid data layout, deferenceable(N) doesn't get parsed or
propagated. Since this is the key item we are testing, add a dependency
on the pass.
Differential Revision: http://reviews.llvm.org/D7508
llvm-svn: 228611
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.
llvm-svn: 228610
While a theoretical GC might change dereferenceability on collection,
there is no such known collector and no need to account for the case
with a flag yet.
Differential Revision: http://reviews.llvm.org/D7454
llvm-svn: 228606
5 minutes is an eternity, so try to strike a better balance between
waiting long enough for any reasonable module build and not so long that
users kill the process because they think it's hanging.
Also give the client a way to delete the lock file after a timeout.
llvm-svn: 228603
