It doesn't have a maintainer and none of the release testers test it,
so I don't think it should be part of the release.
http://reviews.llvm.org/D9331
llvm-svn: 236077
-Wpessimizing-move warns when a call to std::move would prevent copy elision
if the argument was not wrapped in a call. This happens when moving a local
variable in a return statement when the variable is the same type as the
return type or using a move to create a new object from a temporary object.
-Wredundant-move warns when an implicit move would already be made, so the
std::move call is not needed, such as when moving a local variable in a return
that is different from the return type.
Differential Revision: http://reviews.llvm.org/D7633
llvm-svn: 236075
This is necessary in order to allow the use of a constexpr member function, or
a member function with deduced return type, of a local class within a
surrounding instantiated function template specialization.
Patch by Michael Park!
llvm-svn: 236063
in the debug info. This patch deletes a hack that emits the members
of local anonymous unions as local variables.
Besides being morally wrong, the existing representation using local
variables breaks internal assumptions about the local variables' storage
size.
Compiling
```
void fn1() {
union {
int i;
char c;
};
i = c;
}
```
with -g -O3 -verify will cause the verifier to fail after SROA splits
the 32-bit storage for the "local variable" c into two pieces because the
second piece is clearly outside the 8-bit range that is expected for a
variable of type char. Given the choice I'd rather fix the debug
representation than weaken the verifier.
Debuggers generally already know how to deal with anonymous unions when
they are members of C++ record types, but they may have problems finding
the local anonymous struct members in the expression evaluator.
rdar://problem/20730771
llvm-svn: 236059
the profile output from the command line via -fprofile-instr-generate=<path>,
where the specified output path/file will be overridden by the
LLVM_PROFILE_FILE environment variable.
Several changes are made to the runtime to support this:
Add a new interface __llvm_profile_override_default_filename that will
set the profile output filename, but allows LLVM_PROFILE_FILE to override.
This is the interface used by the new option.
Refactor the pid-expansion done for LLVM_PROFILE_FILE into a separate
routine that can be shared by the various filename setting routines
(so that the filename from the option can also use the "%p" syntax).
Move the truncation into setFilename, and only truncate if there is a
new filename specified (to maintain support for appending to the same
profile file in the case of multiple shared objects built with profiling).
Move the handling for a NULL filename passed to __llvm_profile_set_filename and
__llvm_profile_override_default_filename into the new setFilenamePossiblyWithPid
routine. This now correctly resets the output file to default.profraw
instead of NULL.
The handling for a null LLVM_PROFILE_FILE (which should not reset) is done
by caller setFilenameFromEnvironment.
Patch by Teresa Johnson.
llvm-svn: 236055
This is just the clang-side of 32-bit SEH. LLVM still needs work, and it
will determinstically fail to compile until it's feature complete.
On x86, all outlined handlers have no parameters, but they do implicitly
take the EBP value passed in and use it to address locals of the parent
frame. We model this with llvm.frameaddress(1).
This works (mostly), but __finally block inlining can break it. For now,
we apply the 'noinline' attribute. If we really want to inline __finally
blocks on 32-bit x86, we should teach the inliner how to untangle
frameescape and framerecover.
Promote the error diagnostic from codegen to sema. It now rejects SEH on
non-Windows platforms. LLVM doesn't implement SEH on non-x86 Windows
platforms, but there's nothing preventing it.
llvm-svn: 236052
We were trying to look through COPY instructions, but only to the next
instruction in a BB and incorrectly anyway. The cases where that would actually
be a good idea are rare enough (and not even tested!) that it's not worth
trying to get right.
rdar://20721342
llvm-svn: 236050
Summary:
FileScopeAsm should be treated the same as funcion level inline asm.
-fno-gnu-inline-asm should trigger an error if file scope asm is used.
I missed this case from r226340. This should not affect ms-extension
because it is not allowed in the file scope.
Reviewers: bob.wilson, rnk
Reviewed By: rnk
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D9328
llvm-svn: 236044
This is a compromise: with this simple patch, we should always handle a chain of exactly 3
operations optimally, but we're not generating the optimal balanced binary tree for a longer
sequence.
In general, this transform will reduce the dependency chain for a sequence of instructions
using N operands from a worst case N-1 dependent operations to N/2 dependent operations.
The optimal balanced binary tree would reduce the chain to log2(N).
The trade-off for not dealing with longer sequences is: (1) we have less complexity in the
compiler, (2) we avoid unknown compile-time blowup calculating a balanced tree, and (3) we
don't need to worry about the increased register pressure required to parallelize longer
sequences. It also seems unlikely that we would ever encounter really long strings of
dependent ops like that in the wild, but I'm not sure how to verify that speculation.
FWIW, I see no perf difference for test-suite running on btver2 (x86-64) with -ffast-math
and this patch.
We can extend this patch to cover other associative operations such as fmul, fmax, fmin,
integer add, integer mul.
This is a partial fix for:
https://llvm.org/bugs/show_bug.cgi?id=17305
and if extended:
https://llvm.org/bugs/show_bug.cgi?id=21768https://llvm.org/bugs/show_bug.cgi?id=23116
The issue also came up in:
http://reviews.llvm.org/D8941
Differential Revision: http://reviews.llvm.org/D9232
llvm-svn: 236031
Summary:
We don't seem to need to assert here, since this function's callers expect
to get a nullptr on error. This way we don't assert on user input.
Bug found with AFL fuzz.
Reviewers: rafael
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D9308
llvm-svn: 236027
Summary:
The "internal" name of vars is different between clang and GCC. All this
change does is to use a regex instead of the hardcoded internal name.
Test Plan: dotest.py -C <clang|gcc> -p TestMiVar
Reviewers: ki.stfu
Reviewed By: ki.stfu
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D9128
llvm-svn: 236024
We don't need codegen-only intrinsic instructions for the vector forms of these instructions.
This makes the reciprocal estimate instruction lowering identical to how we handle normal
square roots: (V)SQRTPS / (V)SQRTPD.
No existing regression tests fail with this patch.
Differential Revision: http://reviews.llvm.org/D9301
llvm-svn: 236013
some bugs in the ASTImporter that this exposed:
- When importing functions, the body (if any) was
previously ignored. This patch ensures that the
body is imported also.
- When a function-local Decl is imported, the first
thing the ASTImporter does is import its context
(via ImportDeclParts()). This can trigger
importing the Decl again as part of the body of
the function (but only once, since the function's
Decl has been added to ImportedDecls). This patch
fixes that problem by extending ImportDeclParts()
to return the imported Decl if it was imported as
part of importing its context, and the patch adds
ASTImporter::GetAlreadyImportedOrNull() to support
this query. All callers of ImportDeclParts return
the imported version of the Decl if ImportDeclParts()
returns it.
- When creating functions, InnerLocStart of the source
function was re-used without importing. This is a
straight up bug, and this patch makes ASTImporter
import the InnerLocStart and use the imported version.
- When importing FileIDs, the ASTImporter previously
always tried to re-load the file for the corresponding
CacheEntry from disk. This doesn't work if the
CacheEntry corresponds to a named memory buffer. This
patch changes the code so that if the UniqueID for the
cache entry is invalid (i.e., it is not a disk file)
the whole entry is treated as if it were invalid, which
forces an in-memory copy of the buffer.
Also added test cases, using the new support committed in
236011.
llvm-svn: 236012
Nico Weber