| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 185803
|
|
|
|
|
|
|
| |
Use MVC for memcpy in cases where a single MVC is enough. Using MVC is
a win for longer copies too, but I'll leave that for later.
llvm-svn: 185802
|
|
|
|
| |
llvm-svn: 185801
|
|
|
|
| |
llvm-svn: 185800
|
|
|
|
| |
llvm-svn: 185799
|
|
|
|
|
|
|
| |
This is mostly Doxygen formatting, but also updates some C++0x references
to C++11 and clarifies some wording.
llvm-svn: 185798
|
|
|
|
|
|
|
| |
'shell-preserves-root'.
FIXME: Could we introduce another feature for it?
llvm-svn: 185797
|
|
|
|
|
|
|
|
|
|
|
| |
x86_64-unknown-unknown.
It would emit @llvm.memcpy with "-triple x86_64-(mingw32|win32)" and had been failing since Nick's r185735.
; Function Attrs: nounwind
declare void @llvm.memcpy.p0i8.p0i8.i64(i8* nocapture, i8* nocapture readonly, i64, i32, i1) #1
llvm-svn: 185796
|
|
|
|
|
|
|
| |
CXXUnresolvedConstructExpr.SourceRange, for now.
FIXME: It could pass if MS-compatible mode were disabled with Args.push_back("-fno-delayed-template-parsing").
llvm-svn: 185795
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes a bug (found by llvm-stress) in
DAGTypeLegalizer::PromoteIntRes_BUILD_VECTOR where it assumed that the result
type would always be larger than the original operands. This is not always
true, however, with boolean vectors. For example, promoting a node of type v8i1
(where the operands will be of type i32, the type to which i1 is promoted) will
yield a node with a result vector element type of i16 (and operands of type
i32). As a result, we cannot blindly assume that we can ANY_EXTEND the operands
to the result type.
llvm-svn: 185794
|
|
|
|
| |
llvm-svn: 185793
|
|
|
|
| |
llvm-svn: 185792
|
|
|
|
| |
llvm-svn: 185791
|
|
|
|
| |
llvm-svn: 185790
|
|
|
|
|
|
| |
small size of the inner SmallVector.
llvm-svn: 185789
|
|
|
|
| |
llvm-svn: 185788
|
|
|
|
| |
llvm-svn: 185787
|
|
|
|
| |
llvm-svn: 185786
|
|
|
|
| |
llvm-svn: 185785
|
|
|
|
|
|
| |
specifying the vector size.
llvm-svn: 185784
|
|
|
|
|
|
|
|
| |
This fixes an oversight that Intrinsic::nearbyint was not being mapped to
ISD::FNEARBYINT (thus fixing the over-optimistic cost we were assigning to
nearbyint calls for some targets).
llvm-svn: 185783
|
|
|
|
| |
llvm-svn: 185782
|
|
|
|
|
|
| |
This reverts commit 01f8d579f7672872324208ac5bc4ac311e81b22e.
llvm-svn: 185781
|
|
|
|
| |
llvm-svn: 185780
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sema::MergeFunctionDecl attempts merging two decls even if the old decl
is invalid. This can lead to interesting circumstances where we
successfully merge the decls but the result makes no sense.
Take the following for example:
template <typename T>
int main(void);
int main(void);
Sema will not consider these to be overloads of the same name because
main can't be overloaded, which means that this must be a redeclaration.
In this case the templated decl is compatible with the non-templated
decl allowing the Sema::CheckFunctionDeclaration machinery to move on
and do bizarre things like setting the previous decl of a non-templated
decl to a templated decl!
The way I see it, we should just bail from MergeFunctionDecl if the old
decl is invalid.
This fixes PR16531.
llvm-svn: 185779
|
|
|
|
| |
llvm-svn: 185778
|
|
|
|
| |
llvm-svn: 185777
|
|
|
|
|
|
| |
pointer arguments.
llvm-svn: 185776
|
|
|
|
|
|
| |
since it has no callers today.
llvm-svn: 185775
|
|
|
|
|
|
|
|
|
| |
This is a complete re-write if the bottom-up vectorization class.
Before this commit we scanned the instruction tree 3 times. First in search of merge points for the trees. Second, for estimating the cost. And finally for vectorization.
There was a lot of code duplication and adding the DCE exposed bugs. The new design is simpler and DCE was a part of the design.
In this implementation we build the tree once. After that we estimate the cost by scanning the different entries in the constructed tree (in any order). The vectorization phase also works on the built tree.
llvm-svn: 185774
|
|
|
|
|
|
| |
Added testcases.
llvm-svn: 185773
|
|
|
|
|
|
| |
case inspired by a stackoverflow question.
llvm-svn: 185772
|
|
|
|
|
|
|
|
|
| |
* Fix up \brief documentation;
* Update C++0x references to C++11;
* Doxygen formatting: bulleted lists start with a single hyphen, not two;
* Fix a typo, "assosiate" -> "associate".
llvm-svn: 185771
|
|
|
|
|
|
|
| |
Upon further reflection, the alias analysis part of r185764 is not a safe
change.
llvm-svn: 185770
|
|
|
|
|
|
| |
not modify the ref count of an objc object and additionally are inert for modref purposes.
llvm-svn: 185769
|
|
|
|
|
|
| |
brace)
llvm-svn: 185768
|
|
|
|
| |
llvm-svn: 185767
|
|
|
|
|
|
| |
I wish we could typecheck llvm::format.
llvm-svn: 185766
|
|
|
|
| |
llvm-svn: 185765
|
|
|
|
|
|
| |
references to entrypoint declarations as well.
llvm-svn: 185764
|
|
|
|
| |
llvm-svn: 185763
|
|
|
|
|
|
| |
// rdar://14182680.
llvm-svn: 185762
|
|
|
|
|
|
|
|
|
|
|
| |
Obviously the personality function should be emitted as language handler
instead of the hard coded _GCC_specific_handler. The language specific
data must be placed after the unwind information therefore it must not
be emitted into a separate section.
Reviewed by Charles Davis and Nico Rieck.
llvm-svn: 185761
|
|
|
|
|
|
|
|
|
|
|
| |
For alignment purposes, the instruction array will always have an even
number of entries, with the final entry potentially unused (in which
case the array will be one longer than indicated by the count of unwind
codes field).
Reviewed by Charles Davis and Nico Rieck.
llvm-svn: 185760
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
data structures.
The Win64 EH data structures must be of type IMAGE_REL_AMD64_ADDR32NB
instead of IMAGE_REL_AMD64_ADDR32. This is easiely achieved by adding
the VK_COFF_IMGREL32 modifier to the symbol reference.
Change also references to start and end of the SEH range of a function
as offsets to start of the function.
Reviewed by Charles Davis and Nico Rieck.
llvm-svn: 185759
|
|
|
|
|
|
|
|
|
|
|
|
| |
The code offset for unwind code SET_FPREG is wrong because it is set
to constant 0. The fix is to do the same as for the other unwind
codes: emit a label and later the absolute difference between the
label and the begin of the prologue.
Also enables the failing test case MC/COFF/seh.s
Reviewed by Charles Davis and Nico Rieck.
llvm-svn: 185758
|
|
|
|
| |
llvm-svn: 185757
|
|
|
|
| |
llvm-svn: 185756
|
|
|
|
|
|
|
|
|
|
|
|
| |
ReduceLoadWidth unconditionally drops extensions from loads. Limit it to the
case when all of the bits the extension would otherwise produce are dropped by
the shrink. It would be possible to shrink the load in more cases by merging
the extensions, but this isn't trivial and a very rare case. I left a TODO for
that case.
Fixes PR16551.
llvm-svn: 185755
|
|
|
|
|
|
|
|
| |
This prevents the emission of DAG-generated vreg definitions after a
tail call be dropping them entirely (on the grounds that nothing could
use them anyway, and they interfere with O0 CodeGen).
llvm-svn: 185754
|