Block address forward-references are implemented by creating a
`BasicBlock` ahead of time that gets inserted in the `Function` when
it's eventually encountered.
However, if the same blockaddress was used in two separate functions
that were parsed *before* the referenced function (and the blockaddress
was never used at global scope), two separate basic blocks would get
created, one of which would be forgotten creating invalid IR.
This commit changes the forward-reference logic to create only one basic
block (and always return the same blockaddress).
llvm-svn: 215805
This is an off-by-one bug I found by inspection, which would only
trigger if the bitcode writer sees more uses of a `Value` than the
reader. Since this is only relevant when an instruction gets upgraded
somehow, there unfortunately isn't a reasonable way to add test
coverage.
llvm-svn: 215804
Global variables that have `extern_weak` linkage may be null, so it's
incorrect to add `inbounds` when constant folding.
This also fixes a bug when parsing global aliases, whose forward
reference placeholders are global variables with `extern_weak` linkage.
If GEPs to these aliases are encountered before the alias itself, the
GEPs would incorrectly gain the `inbounds` keyword as well.
llvm-svn: 215803
Summary:
This patch does two things:
CMake Update:
- Add compiler flag checks for -std=c++11 and -std=c++1y and remove check for -std=c++0x.
- Add configuration option LIBCXX_ENABLE_CXX1Y to prevent/allow -std=c++1y from being chosen as the std version. LIBCXX_ENABLE_CXX1Y is set to OFF by default.
- if LIBCXX_ENABLE_CXX1Y is enabled then set LIBCXX_STD_VERSION to c++1y and fail if the compiler does not support -std=c++1y
- If c++1y is not enabled then use c++11 and fail if the compiler does not support c++11.
Lit Update:
- Update lit.site.cfg.in to capture LIBCXX_STD_VERSION information as config.std.
- Remove mentions of has_cxx0X configuration option.
- Check for `--param std=X' passed to lit on the command line.
- Choose the std for the tests either from command line parameter or (if it doesn't exist) the lit.site.cfg.
Reviewers: mclow.lists, danalbert
Reviewed By: danalbert
Subscribers: emaste, rnk, ajwong, danalbert, cfe-commits
Differential Revision: http://reviews.llvm.org/D4329
llvm-svn: 215802
When combining a pair of shuffle nodes, check if the combined shuffle mask is
trivially Undef. In case, immediately fold that pair of shuffles to Undef.
The lack of checks for undef masks was the root-cause of a poor-codegen bug
in the dag combiner.
Example:
%1 = shufflevector <4 x i32> %A, <4 x i32> %B, <4 x i32> <i32 4, i32 1, i32 1, i32 6>
%2 = shufflevector <4 x i32> %1, <4 x i32> undef, <4 x i32> <i32 0, i32 4, i32 1, i32 6>
%3 = shufflevector <4 x i32> %2, <4 x i32> undef, <4 x i32> <i32 1, i32 5, i32 3, i32 3>
Before this patch, on x86 (with -mcpu=corei7) we failed to fold the entire
sequence to Undef value and therefore we generated:
shufps $-123, %xmm1, $xmm0
pshufd $-46, %xmm0, %xmm0
With this patch, the entire shuffle sequence is folded to Undef and no
shuffles are generated in the output assembly.
Added new test cases to test 'combine-vec-shuffle-5.ll'.
llvm-svn: 215797
A byval object, even if allocated at a fixed offset (prescribed by the ABI) is
pointed to by IR values. Most fixed-offset stack objects are not pointed-to by
IR values, so the default is to assume this is not possible. However, we need
to override the default in this case (instruction scheduling can cause
miscompiles otherwise).
Fixes PR20280.
llvm-svn: 215795
We used to assume that any fixed-offset stack object was not aliased. This
meant that no IR value could point to the memory contained in such an object.
This is a reasonable default, but is not a universally-correct
target-independent fact. For example, on PowerPC (both Darwin and non-Darwin),
some byval arguments are allocated at fixed offsets by the ABI. These, however,
certainly can be pointed to by IR values. This change moves the 'isAliased'
logic out of FixedStackPseudoSourceValue and into MFI, and allows the isAliased
property to be overridden for fixed-offset objects.
This will be used by an upcoming commit to the PowerPC backend to fix PR20280.
No functionality change intended (the behavior of
FixedStackPseudoSourceValue::isAliased has been made more conservative for
callers that don't pass an MFI object, but I don't see any in-tree callers that
do that).
llvm-svn: 215794
On PPC/Darwin, byval arguments occur at fixed stack offsets in the callee's
frame, but are not immutable -- the pointer value is directly available to the
higher-level code as the address of the argument, and the value of the byval
argument can be modified at the IR level.
This is necessary, but not sufficient, to fix PR20280. When PR20280 is fixed in
a follow-up commit, its test case will cover this change.
llvm-svn: 215793
Previously lldbHost was built as multiple static libraries such as
lldbHostCommon, lldbHostLinux, etc. With this patch, the CMake
build produces only a single static library, lldbHost, whose file
set is dynamically created based on the platform.
llvm-svn: 215792
This reverts commit r215785 / 170ebf4f19459ae51a9561d0e65c87ee4c9b2c97.
LLD has some StringSavers that need to be updated. One of which takes a
lock and I need to investigate that more closely.
llvm-svn: 215791
This reverts commit r215784 / 3f8a26f6fe16cc76c98ab21db2c600bd7defbbaa.
LLD has 3 StringSaver's, one of which takes a lock when saving the
string... Need to investigate more closely.
llvm-svn: 215790
This fixes PR20671, see the bug for details. In short, ActOnTranslationUnit()
calls DefineUsedVTables() and only then PerformPendingInstantiations(). But
PerformPendingInstantiations() is what does delayed template parsing, so
vtables only references from late-parsed templates weren't marked used.
As a fix, move the SavePendingInstantiationsAndVTableUsesRAII in
PerformPendingInstantiations() up above the delayed template parsing code.
That way, vtables referenced from templates end up in the RAII object, and the
call to DefineUsedVTables() in PerformPendingInstantiations() marks them used.
llvm-svn: 215786
There is more cleanup to be done here. Once
llvm::sys::Process::GetArgumentVector is switched over to StringSaver,
we can simplify this code a fair amount.
llvm-svn: 215785
This class is generally useful.
In breaking it out, the primary change is that it has been made
non-virtual. It seems like being abstract led to there being 3 different
(2 in llvm + 1 in clang) concrete implementations which disagreed about
the ownership of the saved strings (see the manual call to free() in the
unittest StrDupSaver; yes this is different from the CommandLine.cpp
StrDupSaver which owns the stored strings; which is different from
Clang's StringSetSaver which just holds a reference to a
std::set<std::string> which owns the strings).
I've identified 2 other places in the
codebase that are open-coding this pattern:
memcpy(Alloc.Allocate<char>(strlen(S)+1), S, strlen(S)+1)
I'll be switching them over. They are
* llvm::sys::Process::GetArgumentVector
* The StringAllocator member of YAMLIO's Input class
This also will allow simplifying Clang's driver.cpp quite a bit.
Let me know if there are any other places that could benefit from
StringSaver. I'm also thinking of adding a saveStringRef member for
getting a stable StringRef.
llvm-svn: 215784
More specifically, this change can be summarized as follows:
1) Makes an lldbHostPosix library which contains code common to
all posix platforms.
2) Creates Host/FileSystem.h which defines a common FileSystem
interface.
3) Implements FileSystem.h in Host/windows and Host/posix.
4) Creates Host/FileCache.h, implemented in Host/common, which
defines a class useful for storing handles to open files needed
by the debugger.
Differential Revision: http://reviews.llvm.org/D4889
llvm-svn: 215775
Currently, if you use a MultiArg<> option, then printing out the help/usage
message will cause an assert. This fixes getOptionHelpName() to work with
MultiArg Options.
llvm-svn: 215770
A little test case simplification - this could be simplified further,
though there are certainly interesting connections to the if/else
construct so I'm hesitant to remove that entirely though it does appear
somewhat unrelated.
(similar fix to r215766, related to PR19864)
llvm-svn: 215768
This avoids debuggers stepping to strange places (like the last
statement in the loop body, or the first statement in the if).
This is not the whole answer, though - similar bugs no doubt exist in
other loops (patches to follow) and attributing exception handling code
to the correct line is also tricky (based on the previous fix to
PR19864, exception handling is still erroneously attributed to the 'if'
line).
llvm-svn: 215766
We were setting the comdat when functions were copied in the initial pass, but
not when they were linked only when we found out that they are needed.
llvm-svn: 215765
The darwin linker has an option, heavily used by Xcode, in which, instead
of listing all input files on the command line, the input file paths are
written to a text file and the path of that text file is passed to the linker
with the -filelist option (similar to @file).
In order to make test cases for this, I generalized the -test_libresolution
option to become -test_file_usage.
llvm-svn: 215762
This also suggests some refactoring to simplify this code. Basically, a
ton of complexity in this argument handling code comes from the need to
save const char *'s in stable storage for pushing onto argv.
It seems like llvm:🆑:StringSaver can be improved to cover all the
needs here.
llvm-svn: 215761
Duncan P. N. Exon Smith