Reid Kleckner [Wed, 6 Jun 2018 01:35:08 +0000 (01:35 +0000)]
Implement bittest intrinsics generically for non-x86 platforms
I tested these locally on an x86 machine by disabling the inline asm
codepath and confirming that it does the same bitflips as we do with the
inline asm.
Craig Topper [Wed, 6 Jun 2018 00:24:55 +0000 (00:24 +0000)]
[X86] Add builtins for vector element insert and extract for different 128 and 256 bit vector types. Use them to implement the extract and insert intrinsics.
Previously we were just using extended vector operations in the header file.
This unfortunately allowed non-constant indices to be used with the intrinsics. This is incompatible with gcc, icc, and MSVC. It also introduces a different performance characteristic because non-constant index gets lowered to a vector store and an element sized load.
By adding the builtins we can check for the index to be a constant and ensure its in range of the vector element count.
User code still has the option to use extended vector operations themselves if they need non-constant indexing.
Craig Topper [Tue, 5 Jun 2018 22:40:03 +0000 (22:40 +0000)]
[X86] Implement __builtin_ia32_vec_ext_v2si correctly even though we only use it with an index of 0.
This builtin takes an index as its second operand, but the codegen hardcodes an index of 0 and doesn't use the operand. The only use of the builtin in the header file passes 0 to the operand so this works for that usage. But its more correct to use the real operand.
Craig Topper [Tue, 5 Jun 2018 21:54:35 +0000 (21:54 +0000)]
[X86] Make __builtin_ia32_vec_ext_v2si require ICE for its index argument. Add warnings for out of range indices for __builtin_ia32_vec_ext_v2si, __builtin_ia32_vec_ext_v4hi, and __builtin_ia32_vec_set_v4hi.
These should take a constant value for an index and that constant should be a valid element number.
Yaxun Liu [Tue, 5 Jun 2018 15:11:02 +0000 (15:11 +0000)]
[CUDA][HIP] Do not emit type info when compiling for device
CUDA/HIP does not support RTTI on device side, therefore there
is no point of emitting type info when compiling for device.
Emitting type info for device not only clutters the IR with useless
global variables, but also causes undefined symbol at linking
since vtable for cxxabiv1::class_type_info has external linkage.
Jeremy Morse [Tue, 5 Jun 2018 09:18:26 +0000 (09:18 +0000)]
Detect an incompatible VLA pointer assignment
For pointer assignments of VLA types, Clang currently detects when array
dimensions _lower_ than a variable dimension differ, and reports a warning.
However it does not do the same when the _higher_ dimensions differ, a
case that GCC does catch.
These two pointer types
int (*foo)[1][bar][3];
int (*baz)[1][2][3];
are compatible with each another, and the program is well formed if
bar == 2, a matter that is the programmers problem. However the following:
int (*qux)[2][2][3];
would not be compatible with either, because the upper dimension differs
in size. Clang reports baz is incompatible with qux, but not that foo is
incompatible with qux because it doesn't check those higher dimensions.
Fix this by comparing array sizes on higher dimensions: if both are
constants but unequal then report incompatibility; if either dimension is
variable then we can't know either way.
Craig Topper [Tue, 5 Jun 2018 03:12:14 +0000 (03:12 +0000)]
[X86] Mark all the builtins and intrinsics that require MMX and an SSE feature as requiring both mmx and the sse feature.
Previously we only checked the sse feature, but this means that if you passed -mno-mmx, the builtins/intrinsics wouldn't be disabled in the frontend and would instead fail backend isel.
Reid Kleckner [Tue, 5 Jun 2018 01:33:40 +0000 (01:33 +0000)]
Reimplement the bittest intrinsic family as builtins with inline asm
We need to implement _interlockedbittestandset as a builtin for
windows.h, so we might as well do the whole family. It reduces code
duplication anyway.
Fixes PR33188, a long standing bug in our bittest implementation
encountered by Chakra.
Reid Kleckner [Mon, 4 Jun 2018 21:39:20 +0000 (21:39 +0000)]
Revert r333791 "Cap "voluntary" vector alignment at 16 for all Darwin platforms."
Adding __attribute__((aligned(32))) to __m256 breaks the implementation
of _mm256_loadu_ps on Windows. On Windows, alignment attributes have
higher precedence than packing attributes.
We also might want to carefully consider the consequences of changing
our vector typedefs, since many users copy them and invent their own
new, non-Intel specific vector type names.
Craig Topper [Mon, 4 Jun 2018 19:28:09 +0000 (19:28 +0000)]
[X86] Avoid passing _mm_undefined* to builtin_shufflevector if we are able to pass the first input a second time.
This is more consistent with other usages of builtin_shufflevector. Later optimization passes or codegen will detect the duplicate vector and replace it with undef. Using _mm_undefined just puts a zeroinitializer that still needs to be optimized out later.
Artem Dergachev [Mon, 4 Jun 2018 18:56:25 +0000 (18:56 +0000)]
[CFG] Fix automatic destructors when a member is bound to a reference.
In code like
const int &x = A().x;
automatic destructor for the object A() lifetime-extended by reference 'x' was
not present in the clang CFG due to ad-hoc pattern-matching in
getReferenceInitTemporaryType().
Re-use skipRValueSubobjectAdjustments() again to find the lifetime-extended
object in the AST and emit the correct destructor.
Lifetime extension through aggregates with references still needs to be covered.
Leonard Chan [Mon, 4 Jun 2018 16:07:52 +0000 (16:07 +0000)]
This diff includes changes for supporting the following types.
// Primary fixed point types
signed short _Accum s_short_accum;
signed _Accum s_accum;
signed long _Accum s_long_accum;
unsigned short _Accum u_short_accum;
unsigned _Accum u_accum;
unsigned long _Accum u_long_accum;
// Aliased fixed point types
short _Accum short_accum;
_Accum accum;
long _Accum long_accum;
This diff only allows for declaration of the fixed point types. Assignment and other operations done on fixed point types according to http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1169.pdf will be added in future patches. The saturated versions of these types and the equivalent _Fract types will also be added in future patches.
The tests included are for asserting that we can declare these types.
Fixed the test that was failing by not checking for dso_local on some
targets.
Summary: This is a prototype of a bug reporter visitor that invalidates bug reports by re-checking constraints of certain states on the bug path using the Z3 constraint manager backend. The functionality is available under the `crosscheck-with-z3` analyzer config flag.
Created a tiny SMT interface and make Z3ConstraintManager implement it
Summary:
This patch implements a simple SMTConstraintManager API, and requires the implementation of two methods for now: `addRangeConstraints` and `isModelFeasible`.
Update Z3ConstraintManager to inherit it and implement required methods.
I also moved the method to dump the SMT formula from D45517 to this patch.
This patch was created based on the reviews from D47640.
Craig Topper [Mon, 4 Jun 2018 02:56:18 +0000 (02:56 +0000)]
[X86] Fix a couple places that were using macro arguments twice when of the usages could just be undefined.
One of the arguments was being used when the passthru argument is unused due to the mask being all 1s. But in that case the actual value doesn't matter so we should use undef instead to avoid expanding the macro argument unnecessarily.
Craig Topper [Sun, 3 Jun 2018 19:42:59 +0000 (19:42 +0000)]
[X86] Replace __builtin_ia32_vbroadcastf128_pd256 and __builtin_ia32_vbroadcastf128_ps256 with an unaligned load intrinsics and a __builtin_shufflevector call.
Craig Topper [Sun, 3 Jun 2018 18:08:36 +0000 (18:08 +0000)]
[X86] When emitting masked loads/stores don't check for all ones mask.
This seems like a premature optimization. It's unlikely a user would pass something the frontend can tell is all ones to the masked load/store intrinsics.
We do this optimization for emitting select for masking because we have builtin calls in header files that pass an all ones mask in. Though at this point we may not longer have any builtins that emit some IR and a select. We may only have the select builtins so maybe we can remove that optimization too.
Leonard Chan [Sat, 2 Jun 2018 02:58:51 +0000 (02:58 +0000)]
This diff includes changes for supporting the following types.
```
// Primary fixed point types
signed short _Accum s_short_accum;
signed _Accum s_accum;
signed long _Accum s_long_accum;
unsigned short _Accum u_short_accum;
unsigned _Accum u_accum;
unsigned long _Accum u_long_accum;
// Aliased fixed point types
short _Accum short_accum;
_Accum accum;
long _Accum long_accum;
```
This diff only allows for declaration of the fixed point types. Assignment and other operations done on fixed point types according to http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1169.pdf will be added in future patches. The saturated versions of these types and the equivalent `_Fract` types will also be added in future patches.
The tests included are for asserting that we can declare these types.
Shoaib Meenai [Sat, 2 Jun 2018 01:22:39 +0000 (01:22 +0000)]
[cmake] Support LLD for CLANG_ORDER_FILE
LLD also supports order files using the `--symbol-ordering-file` option.
As the name would suggest, the order file format is slightly different
from gold; gold's order files specify section names, whereas LLD's
specify symbol names. Assuming you have an order file in the correct
format though, we should support using it with LLD.
Switch the check to actually use LLVM's linker detection rather than
just checking for the presence of the gold executable, since we might
have a gold executable present but be using LLD (or bfd for that matter)
as our linker.
John McCall [Fri, 1 Jun 2018 21:34:26 +0000 (21:34 +0000)]
Cap "voluntary" vector alignment at 16 for all Darwin platforms.
This fixes two major problems:
- We were not capping vector alignment as desired on 32-bit ARM.
- We were using different alignments based on the AVX settings on
Intel, so we did not have a consistent ABI.
This is an ABI break, but we think we can get away with it because
vectors tend to be used mostly in inline code (which is why not having
a consistent ABI has not proven disastrous on Intel).
Intel's AVX types are specified as having 32-byte / 64-byte alignment,
so align them explicitly instead of relying on the base ABI rule.
Note that this sort of attribute is stripped from template arguments
in template substitution, so there's a possibility that code templated
over vectors will produce inadequately-aligned objects. The right
long-term solution for this is for alignment attributes to be
interpreted as true qualifiers and thus preserved in the canonical type.
Craig Topper [Fri, 1 Jun 2018 18:26:35 +0000 (18:26 +0000)]
[X86] Rewrite avx512vbmi unmasked and maskz macro intrinsics to be wrappers around their __builtin function with appropriate arguments rather than just passing arguments to the masked intrinsic.
This is more consistent with all of our other avx512 macro intrinsics.
It also fixes a bad cast where an argument was casted to mmask8 when it should have been a mmask16.
Nico Weber [Fri, 1 Jun 2018 14:59:57 +0000 (14:59 +0000)]
clang-cl: Expose -no-canonical-prefixes
-no-canonical-prefixes is a weird flag: In gcc, it controls whether realpath()
is called on the path of the driver binary. It's needed to support some
usecases where gcc is symlinked to, see
https://gcc.gnu.org/ml/gcc/2011-01/msg00429.html for some background.
In clang, the resource dir is found relative to the compiler binary, and
without -no-canonical-prefixes that's an absolute path. For clang, the main use
case for -no-canonical-prefixes is to make the -resource-dir path added by the
driver relative instead of absolute. Making it relative seems like the better
default, but since neither clang not gcc have -canonical-prefixes without no-
which makes changing the default tricky, and since some symlink behaviors do
depend on the realpath() call at least for gcc, just expose
-no-canonical-prefixes in clang-cl mode.
Alternatively we could default to no-canonical-prefix-mode for clang-cl since
it's less likely to be used in symlinked scenarios, but since you already need
to about -no-canonical-prefixes for the non-clang-cl bits of your build, not
hooking this of driver mode seems better to me.
Erich Keane [Fri, 1 Jun 2018 13:04:26 +0000 (13:04 +0000)]
[OpenCL, OpenMP] Fix crash when OpenMP used in OpenCL file
Compiler crashes when omp simd is used in an OpenCL file:
clang -c -fopenmp omp_simd.cl
__kernel void test(global int *data, int size) {
#pragma omp simd
for (int i = 0; i < size; ++i) {
}
}
The problem seems to be the check added to verify block pointers have
initializers. An OMPCapturedExprDecl is created to capture ‘size’ but there is
no TypeSourceInfo.
Ilya Biryukov [Fri, 1 Jun 2018 09:49:53 +0000 (09:49 +0000)]
[CodeComplete] Add a few extra tests for r333538. NFC
From a follow-up discussion in D44480.
New tests check that function bodies are not skipped:
- In presence of ptr declarators, e.g. `auto**`.
- When `decltype(auto)` is used in return type, only `auto` was checked before.
Artem Dergachev [Fri, 1 Jun 2018 01:59:48 +0000 (01:59 +0000)]
[analyzer] NFC: Track all constructed objects in a single state trait.
ExprEngine already maintains three internal program state traits to track
path-sensitive information related to object construction: pointer returned by
operator new, and pointer to temporary object for two different purposes - for
destruction and for lifetime extension. We'll need to add 2-3 more in a few
follow-up commits.
Merge these traits into one because they all essentially serve one purpose and
work similarly.
[Modules] Warning for module declarations lacking 'framework' qualifier
When a module declaration for a framework lacks the 'framework'
qualifier, the listed headers aren't found (because there's no
trigger for the special framework style path lookup) and the module
is silently not built. This leads to frameworks not being modularized
by accident, which is pretty bad.
Add a warning and suggest the user to add the 'framework' qualifier
when we can prove that it's the case.
Heejin Ahn [Fri, 1 Jun 2018 01:01:37 +0000 (01:01 +0000)]
[WebAssembly] Hide new Wasm EH behind its feature flag
Summary:
clang's current wasm EH implementation is a non-MVP feature in progress.
We had a `-mexception-handling` wasm feature but were not using it. This
patch hides the non-MVP wasm EH behind a flag, so it does not affect
other code for now.
Dan Gohman [Fri, 1 Jun 2018 00:05:51 +0000 (00:05 +0000)]
[WebAssembly] Update to the new names for the memory builtin functions.
The WebAssembly committee has decided on the names `memory.size` and
`memory.grow` for the memory intrinsics, so update the clang builtin
functions to follow those names, keeping both sets of old names in place
for compatibility.
Heejin Ahn [Thu, 31 May 2018 22:18:13 +0000 (22:18 +0000)]
[WebAssembly] Use Windows EH instructions for Wasm EH
Summary:
Because wasm control flow needs to be structured, using WinEH
instructions to support wasm EH brings several benefits. This patch
makes wasm EH uses Windows EH instructions, with some changes:
1. Because wasm uses a single catch block to catch all C++ exceptions,
this merges all catch clauses into a single catchpad, within which we
test the EH selector as in Itanium EH.
2. Generates a call to `__clang_call_terminate` in case a cleanup
throws. Wasm does not have a runtime to handle this.
3. In case there is no catch-all clause, inserts a call to
`__cxa_rethrow` at the end of a catchpad in order to unwind to an
enclosing EH scope.
Reid Kleckner [Thu, 31 May 2018 18:42:29 +0000 (18:42 +0000)]
Fix null MSInheritanceAttr deref in CXXRecordDecl::getMSInheritanceModel()
Ensure latest MPT decl has a MSInheritanceAttr when instantiating
templates, to avoid null MSInheritanceAttr deref in
CXXRecordDecl::getMSInheritanceModel().
Artem Dergachev [Thu, 31 May 2018 18:30:41 +0000 (18:30 +0000)]
[analyzer] Annotate ProgramState update methods with LLVM_NODISCARD.
Because our program states are immutable, methods like "add<>", "set<>", "bind"
create a copy of the program state instead of mutating the existing state.
If the updated state is discarded, it clearly indicates a bug.
Such bugs are introduced frequently, hence the warn_unused_result annotation.
Artem Dergachev [Thu, 31 May 2018 17:22:38 +0000 (17:22 +0000)]
[analyzer] Improve performance of the SVal simplification mechanism.
When neither LHS nor RHS of a binary operator expression can be simplified,
return the original expression instead of re-evaluating the binary operator.
Such re-evaluation was causing recusrive re-simplification which caused
the algorithmic complexity to explode.
Aaron Ballman [Thu, 31 May 2018 13:57:09 +0000 (13:57 +0000)]
Add a new driver mode to dump compiler feature and extension options.
Add the ability to dump compiler option-related information to a JSON file via the -compiler-options-dump option. Specifically, it dumps the features/extensions lists -- however, this output could be extended to other information should it be useful. In order to support features and extensions, I moved them into a .def file so that we could build the various lists we care about from them without a significant increase in maintenance burden.
David Stenberg [Thu, 31 May 2018 09:05:22 +0000 (09:05 +0000)]
[Driver] Clean up tmp files when deleting Compilation objects
Summary:
In rL327851 the createUniqueFile() and createTemporaryFile()
variants that do not return the file descriptors were changed to
create empty files, rather than only check if the paths are free.
This change was done in order to make the functions race-free.
That change led to clang-tidy (and possibly other tools) leaving
behind temporary assembly files, of the form placeholder-*, when
using a target that does not support the internal assembler.
The temporary files are created when building the Compilation
object in stripPositionalArgs(), as a part of creating the
compilation database for the arguments after the double-dash. The
files are created by Driver::GetNamedOutputPath().
Fix this issue by cleaning out temporary files at the deletion of
Compilation objects.
This fixes https://bugs.llvm.org/show_bug.cgi?id=37091.
Craig Topper [Thu, 31 May 2018 00:51:20 +0000 (00:51 +0000)]
[X86] Remove __extension__ from macro intrinsics when its not needed.
I think this is a holdover from when we used to declare variables inside the macros. And then its been copy and pasted forward for years every time a new macro intrinsic gets added.
Interestingly this caused some tests for IRGen to be slightly more optimized. We now return a zeroinitializer directly instead of going through a store+load.
It also removed a bogus error message on another test.
George Karpenkov [Thu, 31 May 2018 00:28:13 +0000 (00:28 +0000)]
[analyzer] Trust _Nonnull annotations, and trust analyzer knowledge about receiver nullability
Previously, the checker was using the nullability of the expression,
which is nonnull IFF both receiver and method are annotated as _Nonnull.
However, the receiver could be known to the analyzer to be nonnull
without being explicitly marked as _Nonnull.
Vedant Kumar [Wed, 30 May 2018 23:35:44 +0000 (23:35 +0000)]
[Coverage] Discard the last uncompleted deferred region in a decl
Discard the last uncompleted deferred region in a decl, if one exists.
This prevents lines at the end of a function containing only whitespace
or closing braces from being marked as uncovered, if they follow a
region terminator (return/break/etc).
The previous behavior was to heuristically complete deferred regions at
the end of a decl. In practice this ended up being too brittle for too
little gain. Users would complain that there was no way to reach full
code coverage because whitespace at the end of a function would be
marked uncovered.
Joel E. Denny [Wed, 30 May 2018 18:33:53 +0000 (18:33 +0000)]
[AST] Fix loss of enum forward decl from decl context
For example, given:
enum __attribute__((deprecated)) T *p;
-ast-print produced:
enum T *p;
The attribute was lost because the enum forward decl was lost.
Another example is the loss of enum forward decls from C++ namespaces
(in MS compatibility mode).
The trouble was that the EnumDecl node was suppressed, as revealed by
-ast-dump. The suppression of the EnumDecl was intentional in
r116122, but I don't understand why. The suppression isn't needed for
the test suite to behave.
Gabor Buella [Wed, 30 May 2018 15:27:49 +0000 (15:27 +0000)]
[X86] Lowering FMA intrinsics to native IR (Clang part)
This patch replaces all packed (and scalar without rounding
mode) fused intrinsics with fmadd/fmaddsub variations.
Then fmadd/fmaddsub are lowered to native IR.
Ben Hamilton [Wed, 30 May 2018 15:21:38 +0000 (15:21 +0000)]
[clang-format/ObjC] Correctly parse Objective-C methods with 'class' in name
Summary:
Please take a close look at this CL. I haven't touched much of
`UnwrappedLineParser` before, so I may have gotten things wrong.
Previously, clang-format would incorrectly format the following:
```
@implementation Foo
- (Class)class {
}
- (void)foo {
}
@end
```
as:
```
@implementation Foo
- (Class)class {
}
- (void)foo {
}
@end
```
The problem is whenever `UnwrappedLineParser::parseStructuralElement()`
sees any of the keywords `class`, `struct`, or `enum`, it calls
`parseRecord()` to parse them as a C/C++ record.
This causes subsequent lines to be parsed incorrectly, which
causes them to be indented incorrectly.
In Objective-C/Objective-C++, these keywords are valid selector
components.
This diff fixes the issue by explicitly handling `+` and `-` lines
inside `@implementation` / `@interface` / `@protocol` blocks
and parsing them as Objective-C methods.
Test Plan: New tests added. Ran tests with:
make -j16 FormatTests && ./tools/clang/unittests/Format/FormatTests
projects / clang / log