| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
| |
llvm-svn: 208081
|
| |
|
|
|
|
|
| |
No tests here, they'll be added when the entire neon-diagnostics.s test from
AArch64 is enabled.
llvm-svn: 208079
|
| |
|
|
| |
llvm-svn: 208076
|
| |
|
|
|
|
| |
This is the modification in llvm part.
llvm-svn: 208074
|
| |
|
|
| |
llvm-svn: 208064
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
non-temporary copy and using that to RAUW.
Also, provide the ability to create temporary and non-temporary
declarations, as not all declarations may be replaced by definitions
later on.
This provides the necessary infrastructure for Clang to fix PR19598,
leaking temporary MDNodes in Clang's debug info generation.
llvm-svn: 208054
|
| |
|
|
|
|
| |
this reapplies 208012 and 208002.
llvm-svn: 208037
|
| |
|
|
| |
llvm-svn: 208035
|
| |
|
|
|
|
| |
which GCC detects and Clang does not!
llvm-svn: 208033
|
| |
|
|
| |
llvm-svn: 208030
|
| |
|
|
|
|
|
|
|
|
| |
The Win64 docs are very clear that anything larger than 8 bytes is
passed by reference, and GCC MinGW64 honors that for __modti3 and
friends.
Patch by Jameson Nash!
llvm-svn: 208029
|
| |
|
|
|
|
| |
about the use case for the new parameter.
llvm-svn: 208026
|
| |
|
|
|
|
| |
type-erased reference to a callable object.
llvm-svn: 208025
|
| |
|
|
|
|
|
|
|
| |
On x64, windows.h doesn't include intrin.h for intrinsics. It just
declares them in the global namespace and uses them, expecting the
compiler to lower it as a builtin. We basically need to do this in
clang, eventually.
llvm-svn: 208023
|
| |
|
|
|
|
|
|
| |
make sure to zero-initialize the rest
of the buffer if we unexpectedly reach end-of-file while reading.
llvm-svn: 208021
|
| |
|
|
| |
llvm-svn: 208019
|
| |
|
|
|
|
|
|
|
|
| |
calls marked tail in the IR to 470k, however this improvement does not carry into an improvement of the call/jmp ratio on x86. The most common pattern is a tail call + br to a block with nothing but a 'ret'.
The number of tail call to loop conversions remains the same (1618 by my count).
The new algorithm does a local scan over the use-def chains to identify local "alloca-derived" values, as well as points where the alloca could escape. Then, a visit over the CFG marks blocks as being before or after the allocas have escaped, and annotates the calls accordingly.
llvm-svn: 208017
|
| |
|
|
|
|
| |
used via dragonegg for now.
llvm-svn: 208016
|
| |
|
|
|
|
| |
fixed by r207983. <radar://16641956>
llvm-svn: 208013
|
| |
|
|
|
|
| |
and inline it into its caller.
llvm-svn: 208012
|
| |
|
|
|
|
| |
a 0 as a default answer.
llvm-svn: 208009
|
| |
|
|
|
|
|
|
| |
'IsVolatile' for the open file functions.
This provides a hint that the file may be changing often so mmap is avoided.
llvm-svn: 208007
|
| |
|
|
| |
llvm-svn: 208006
|
| |
|
|
| |
llvm-svn: 208005
|
| |
|
|
| |
llvm-svn: 208002
|
| |
|
|
| |
llvm-svn: 207996
|
| |
|
|
|
|
| |
This reverts commit 207992. I misread the phab number on the LGTM.
llvm-svn: 207993
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Also ran clang-format on the function. The code added is the last else
if block.
Reviewers: nadav, craig.topper
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D3518
llvm-svn: 207992
|
| |
|
|
|
|
|
| |
Our OpenGL driver needs 22 SGPRs (16 user SGPRs + 6 streamout non-user SGPRs).
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
llvm-svn: 207990
|
| |
|
|
|
|
| |
<rdar://problem/16812145>
llvm-svn: 207983
|
| |
|
|
|
|
|
|
|
| |
Visibility is meaningless when the linkage is local. Change
`-internalize` to reset the visibility to `default`.
<rdar://problem/16141113>
llvm-svn: 207979
|
| |
|
|
|
|
|
|
|
|
| |
Tested that the right -target-cpu is set in the clang -cc1 command line
when running "clang -march=native -E -v - </dev/null" on both an FX-8150
and an FX-8350. Both are family 15h; the FX-8150 (Bulldozer processor)
reports a model number of 1, and the FX-8350 (Piledriver processor)
reports a model number of 2.
llvm-svn: 207973
|
| |
|
|
|
|
|
|
|
| |
callbacks
See https://code.google.com/p/address-sanitizer/issues/detail?id=305
Reviewed at http://reviews.llvm.org/D3607
llvm-svn: 207968
|
| |
|
|
| |
llvm-svn: 207967
|
| |
|
|
|
|
|
|
| |
Windows on ARM does not conform to AEABI. However, memset would be emitted
using the AEABI signature, resulting in inverted parameters. Handle this
special case appropriately.
llvm-svn: 207943
|
| |
|
|
|
|
|
|
|
| |
Add handling for FK_SecRel_4 (4-byte section relative relocations). These are
used by the generation of DWARF debug information (the abbrevations use section
relative relocations). This will also be used in generation of CodeView line
tables.
llvm-svn: 207941
|
| |
|
|
|
|
|
|
|
|
|
| |
limit unrolling.
Otherwise we use the same threshold as for complete unrolling, which is
way too high. This made us unroll any loop smaller than 150 instructions
by 8 times, but only if someone specified -march=core2 or better,
which happens to be the default on darwin.
llvm-svn: 207940
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When can't assume a vectorized tree is rooted in an instruction. The IRBuilder
could have constant folded it. When we rebuild the build_vector (the series of
InsertElement instructions) use the last original InsertElement instruction. The
vectorized tree root is guaranteed to be before it.
Also, we can't assume that the n-th InsertElement inserts the n-th element into
a vector.
This reverts r207746 which reverted the revert of the revert of r205018 or so.
Fixes the test case in PR19621.
llvm-svn: 207939
|
| |
|
|
| |
llvm-svn: 207937
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
operations on the call graph. This one forms a cycle, and while not as
complex as removing an internal edge from an SCC, it involves
a reasonable amount of work to find all of the nodes newly connected in
a cycle.
Also somewhat alarming is the worst case complexity here: it might have
to walk roughly the entire SCC inverse DAG to insert a single edge. This
is carefully documented in the API (I hope).
llvm-svn: 207935
|
| |
|
|
|
|
| |
Use more range loops in the X86AsmPrinter. NFC.
llvm-svn: 207928
|
| |
|
|
|
|
| |
Remove dead code. This is vestigial after r98384.
llvm-svn: 207927
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Both MinGW and cygwin (i686) construct export directives without the global
leader prefix. This is mostly due to the fact that they use GNU ld which does
not correctly handle the export directive. This apparently has been been broken
for a while. However, this was recently reported as being broken by
mingwandroid and diorcety of the msys2 project.
Remove the global leader prefix if targeting MinGW or cygwin, otherwise, retain
the global leader prefix. Add an explicit test for cygwin's behaviour of export
directives.
llvm-svn: 207926
|
| |
|
|
|
|
|
|
|
| |
Create a helper function to generate the export directive. This was previously
duplicated inline to handle export directives for variables and functions. This
also enables the use of range-based iterators for the generation of the
directive rather than the traditional loops. NFC.
llvm-svn: 207925
|
| |
|
|
|
|
|
| |
We don't modify the AttrBuilder in AttributeSet::get, make the reference
argument const.
llvm-svn: 207924
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fix simply ensures that both metadata nodes are path-aware before
performing path-aware alias analysis.
This issue isn't normally triggered in LLVM, because we perform an autoupgrade
of the TBAA metadata to the new format when reading in LL or BC files. This
issue only appears when a client creates the IR manually and mixes old and new
TBAA metadata format.
This fixes <rdar://problem/16760860>.
llvm-svn: 207923
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The fix itself is fairly simple: move getAccessVariant to MCValue so that we
replace the old weak expression evaluation with the far more general
EvaluateAsRelocatable.
This then requires that EvaluateAsRelocatable stop when it finds a non
trivial reference kind. And that in turn requires the ELF writer to look
harder for weak references.
Last but not least, this found a case where we were being bug by bug
compatible with gas and accepting an invalid input. I reported pr19647
to track it.
llvm-svn: 207920
|
| |
|
|
|
|
| |
http://reviews.llvm.org/D3598
llvm-svn: 207917
|
| |
|
|
|
|
|
|
| |
There is no point in creating it if we're not going to vectorize
anything. Creating the map is expensive as it creates large values.
No functionality change.
llvm-svn: 207916
|
| |
|
|
| |
llvm-svn: 207915
|