externally to simplify our integration of GoogleTest into LLVM. Also,
build the single source file gtest-all.cc instead of the individual
source files as we don't expect these to change and thus gain nothing
from increased incrementality in compiles.
This makes our standard build of googletest exactly like upstream's
recommended build and the sanitizer's build. It also simplifies the
steps of importing a new version should we ever want one.
llvm-svn: 194801
I was able to successfully run a bootstrapped LTO build of clang with
r194701, so this change does not seem to be the cause of our failing
buildbots.
llvm-svn: 194789
This is to avoid this transformation in some cases:
fold (conv (load x)) -> (load (conv*)x)
On architectures that don't natively support some vector
loads efficiently casting the load to a smaller vector of
larger types and loading is more efficient.
Patch by Micah Villmow.
llvm-svn: 194783
While the test would work with any compiled in target with object
emission support, it's nontrivial to formulate this condition in
lit, so a conservative restriction is used instead.
llvm-svn: 194781
This reverts commit 194701. Apple's bootstrapped LTO builds have been failing,
and this change (along with compiler-rt 194702-194704) is the only thing on
the blamelist. I will either reappy these changes or help debug the problem,
depending on whether this fixes the buildbots.
llvm-svn: 194780
This commit brings the module structure, argument order and
primitive names in Llvm_target in order with the rest of the bindings,
in preparation for adding TargetMachine API.
llvm-svn: 194773
short form. Constant islands will expand them if they are out of range.
Since there is not direct object emitter at this time, it does not
have any material affect because the assembler sorts this out. But we
need to know for the actual constant island work. We track the difference
by putting # 16 inst in the comments.
llvm-svn: 194766
Including only Debug.h did not cause a compilation error, but you couldn't
do anything (like writing something with <<) to raw_ostreams returned by
llvm::dbgs() or llvm::errs() without including raw_ostream.h. So including
it from Debug.h should make sense.
Differential Revision: http://llvm-reviews.chandlerc.com/D2183
llvm-svn: 194759
The LDS output queue is accessed via the OQAP register. The OQAP
register cannot be live across clauses, so if value is written to the
output queue, it must be retrieved before the end of the clause.
With the machine scheduler, we cannot statisfy this constraint, because
it lacks proper alias analysis and it will mark some LDS accesses as
having a chain dependency on vertex fetches. Since vertex fetches
require a new clauses, the dependency may end up spiltting OQAP uses and
defs so the end up in different clauses. See the lds-output-queue.ll
test for a more detailed explanation.
To work around this issue, we now combine the LDS read and the OQAP
copy into one instruction and expand it after register allocation.
This patch also adds some checks to the EmitClauseMarker pass, so that
it doesn't end a clause with a value still in the output queue and
removes AR.X and OQAP handling from the scheduler (AR.X uses and defs
were already being expanded post-RA, so the scheduler will never see
them).
Reviewed-by: Vincent Lejeune <vljn at ovi.com>
llvm-svn: 194755
subdirectories. The only thing needed here is to create the appropriate
object file directories and add those as dependencies for the
compilation rules.
As a consequence, factor the non-source-file-specific dependencies for
compilation rules into a helper variable. This fixes an issue where the
project makefile wasn't actually a dependency of a bunch of compilation
make rules for no apparant reason.
This should have no observable effect for current makefile usage, but
will simplify how we build other libraries and is something CMake
already supports.
llvm-svn: 194753
This comes into play with patchpoint, which can fold multiple
operands. Since the patchpoint is already treated as a call, the
machine mem operands won't affect anything, and there's nothing to
test. But we still want to do the right thing here to be sure that our
MIs obey the rules.
llvm-svn: 194750
Summary:
Some machine-type-neutral object files containing only undefined symbols
actually do exist in the Windows standard library. Need to recognize them
as COFF files.
Reviewers: Bigcheese
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D2164
llvm-svn: 194734
In ELF and COFF an alias is just another offset in a section. There is no way
to represent an alias to something in another file.
In MachO, the spec has the N_INDR type which should allow for exactly that, but
is not currently implemented. Given that it is specified but not implemented,
we error in codegen to avoid miscompiling but don't reject aliases to
declarations in the verifier to leave the option open of implementing it.
In the past we have used alias to declarations as a way of implementing
weakref, which is why it exists in some old tests which this patch updates.
llvm-svn: 194705
Indirect call wrapping helps MSanDR (dynamic instrumentation companion tool
for MSan) to catch all cases where execution leaves a compiler-instrumented
module by allowing the tool to rewrite targets of indirect calls.
This change is an optimization that skips wrapping for calls when target is
inside the current module. This relies on the linker providing symbols at the
begin and end of the module code (or code + data, does not really matter).
Gold linker provides such symbols by default. GNU (BFD) linker needs a link
flag: -Wl,--defsym=__executable_start=0.
More info:
https://code.google.com/p/memory-sanitizer/wiki/MSanDR#Native_exec
llvm-svn: 194697