| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 165950
|
| |
|
|
| |
llvm-svn: 165949
|
| |
|
|
| |
llvm-svn: 165947
|
| |
|
|
|
|
|
|
|
| |
inline assembly. For the time being, these will be called directly by clang.
However, in the near future I expect these to be sunk back into the MC layer
and more basic APIs (e.g., getClobbers(), getConstraints(), etc.) will be called
by clang.
llvm-svn: 165946
|
| |
|
|
| |
llvm-svn: 165945
|
| |
|
|
| |
llvm-svn: 165944
|
| |
|
|
|
|
| |
created.
llvm-svn: 165943
|
| |
|
|
|
|
| |
different pointer sizes on a per address space basis.
llvm-svn: 165941
|
| |
|
|
|
|
|
| |
This patch replaces the EmitRawText by a EmitTCEntry class (specialized for
each Streamer) in PowerPC64 TOC entry creation.
llvm-svn: 165940
|
| |
|
|
|
|
|
|
| |
Use internal_memmove() and internal_memcpy() in the memcpy() and memmove() wrappers
when building the dynamic runtime (OS X only), to work around a bug in resolver functions wrapping.
See also http://code.google.com/p/address-sanitizer/issues/detail?id=116
llvm-svn: 165939
|
| |
|
|
| |
llvm-svn: 165938
|
| |
|
|
|
|
| |
clang part: for FunctionPass we need to run asan at a different point, otherwise it will run before inlining
llvm-svn: 165937
|
| |
|
|
|
|
| |
This will simplify chaining other FunctionPasses with asan. Also some minor cleanup
llvm-svn: 165936
|
| |
|
|
| |
llvm-svn: 165934
|
| |
|
|
|
| |
Review: http://llvm-reviews.chandlerc.com/D62
llvm-svn: 165933
|
| |
|
|
|
|
| |
after 'AddressSanitizer' and b) changed 'crashed' to 'SEGV'
llvm-svn: 165932
|
| |
|
|
|
|
|
|
| |
includes extracting ints for copying elsewhere and inserting ints when
copying into the alloca. This should fix the CanSROA assertion coming
out of Clang's regression test suite.
llvm-svn: 165931
|
| |
|
|
|
|
|
| |
and generally clean up the memset handling. It had rotted a bit as the
other rewriting logic got polished more.
llvm-svn: 165930
|
| |
|
|
|
|
| |
VDUPLANE node with the vector input size different from the output size. This was bacause the BUILD_VECTOR lowering code didn't check that the size of the input vector was correct for using VDUPLANE.
llvm-svn: 165929
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
cases where we have partial integer loads and stores to an otherwise
promotable alloca to widen[1] those loads and stores to cover the entire
alloca and bitcast them into the appropriate type such that promotion
can proceed.
These partial loads and stores stem from an annoying confluence of ARM's
calling convention and ABI lowering and the FCA pre-splitting which
takes place in SROA. Clang lowers a { double, double } in-register
function argument as a [4 x i32] function argument to ensure it is
placed into integer 32-bit registers (a really unnerving implicit
contract between Clang and the ARM backend I would add). This results in
a FCA load of [4 x i32]* from the { double, double } alloca, and SROA
decomposes this into a sequence of i32 loads and stores. Inlining
proceeds, code gets folded, but at the end of the day, we still have i32
stores to the low and high halves of a double alloca. Widening these to
be i64 operations, and bitcasting them to double prior to loading or
storing allows promotion to proceed for these allocas.
I looked quite a bit changing the IR which Clang produces for this case
to be more friendly, but small changes seem unlikely to help. I think
the best representation we could use currently would be to pass 4 i32
arguments thereby avoiding any FCAs, but that would still require this
fix. It seems like it might eventually be nice to somehow encode the ABI
register selection choices outside of the parameter type system so that
the parameter can be a { double, double }, but the CC register
annotations indicate that this should be passed via 4 integer registers.
This patch does not address the second problem in PR14059, which is the
reverse: when a struct alloca is loaded as a *larger* single integer.
This patch also does not address some of the code quality issues with
the FCA-splitting. Those don't actually impede any optimizations really,
but they're on my list to clean up.
[1]: Pedantic footnote: for those concerned about memory model issues
here, this is safe. For the alloca to be promotable, it cannot escape or
have any use of its address that could allow these loads or stores to be
racing. Thus, widening is always safe.
llvm-svn: 165928
|
| |
|
|
|
|
|
| |
into static helper functions. They're really quite generic and are going
to be needed elsewhere shortly.
llvm-svn: 165927
|
| |
|
|
| |
llvm-svn: 165925
|
| |
|
|
|
|
| |
This gets rid of some magic numbers.
llvm-svn: 165924
|
| |
|
|
|
|
| |
of a constructor.
llvm-svn: 165923
|
| |
|
|
| |
llvm-svn: 165922
|
| |
|
|
|
|
|
|
| |
description. Previously, one could emulate this behavior by placing
the header in an always-unavailable submodule, but Argyrios guilted me
into expressing this idea properly.
llvm-svn: 165921
|
| |
|
|
|
|
| |
be opaque.
llvm-svn: 165920
|
| |
|
|
|
|
|
|
| |
Convert the uses of the Attributes class over to the new format. The
Attributes::get method call now takes an LLVM context so that the attributes
object can be uniquified and stored.
llvm-svn: 165918
|
| |
|
|
|
|
|
|
|
|
| |
Convert the internal representation of the Attributes class into a pointer to an
opaque object that's uniqued by and stored in the LLVMContext object. The
Attributes class then becomes a thin wrapper around this opaque
object. Eventually, the internal representation will be expanded to include
attributes that represent code generation options, etc.
llvm-svn: 165917
|
| |
|
|
|
|
|
| |
This patch migrates the strcmp and strncmp optimizations from the
simplify-libcalls pass into the instcombine library call simplifier.
llvm-svn: 165915
|
| |
|
|
|
|
| |
fails to return a value, to make debugging this issue easier.
llvm-svn: 165914
|
| |
|
|
|
|
|
| |
a problem with __int128 arithmetic but the runtime was not built with __int128
support.
llvm-svn: 165913
|
| |
|
|
| |
llvm-svn: 165912
|
| |
|
|
|
|
| |
compiling modules.
llvm-svn: 165911
|
| |
|
|
|
|
|
|
| |
This reduces the spam make test leaves behind in /tmp. The assert isn't
particularly useful because it's not run with -disable-free (the default when
using the clang driver) but should cover all -cc1 tests.
llvm-svn: 165910
|
| |
|
|
| |
llvm-svn: 165908
|
| |
|
|
|
|
| |
Add a basic unit test for ImmutableMap. Found by inspection.
llvm-svn: 165907
|
| |
|
|
| |
llvm-svn: 165905
|
| |
|
|
| |
llvm-svn: 165904
|
| |
|
|
|
|
|
|
|
| |
Erasing from the beginning or middle of the vector is expensive, remove_if can
do it in linear time even though it's a bit ugly without lambdas.
No functionality change.
llvm-svn: 165903
|
| |
|
|
| |
llvm-svn: 165902
|
| |
|
|
| |
llvm-svn: 165900
|
| |
|
|
| |
llvm-svn: 165899
|
| |
|
|
|
|
| |
Can't follow the intrusive linked list when the element is gone.
llvm-svn: 165898
|
| |
|
|
| |
llvm-svn: 165897
|
| |
|
|
|
|
| |
the equivalent from the builder class.
llvm-svn: 165896
|
| |
|
|
|
|
| |
it with the equivalent from the builder class.
llvm-svn: 165895
|
| |
|
|
|
|
| |
the equivalent from the builder class.
llvm-svn: 165894
|
| |
|
|
|
|
| |
the equivalent from the builder class.
llvm-svn: 165893
|
| |
|
|
|
|
| |
the equivalent from the builder class.
llvm-svn: 165892
|