[OPENMP] Generate threadprivates as TLS variables by default.
If target supports TLS all threadprivates are generated as TLS. If target does not support TLS, use runtime calls for proper codegen of threadprivate variables.
[OPENMP] Propagate alignment from original variables to the private copies.
Currently private copies of captured variables have default alignment. Patch makes private variables to have same alignment as original variables.
[OPENMP] Outlined function for parallel and other regions with list of captured variables.
Currently all variables used in OpenMP regions are captured into a record and passed to outlined functions in this record. It may result in some poor performance because of too complex analysis later in optimization passes. Patch makes to emit outlined functions for parallel-based regions with a list of captured variables. It reduces code for 2*n GEPs, stores and loads at least.
Codegen for task-based regions remains unchanged because runtime requires that all captured variables are passed in captured record.
David Majnemer [Thu, 10 Sep 2015 07:20:05 +0000 (07:20 +0000)]
[MS ABI] Select a pointer to member representation more often
Given a reference to a pointer to member whose class's inheritance model
is unspecified, make sure we come up with an inheritance model in
plausible places. One place we were missing involved LValue to RValue
conversion, another involved unary type traits.
This flag causes the compiler to emit bit set entries for functions as well
as runtime bitset checks at indirect call sites. Depends on the new function
bitset mechanism.
Mehdi Amini [Thu, 10 Sep 2015 01:46:39 +0000 (01:46 +0000)]
EmitRecord* API change: accepts ArrayRef instead of a SmallVector (NFC)
This reapply a variant commit r247179 after post-commit review from
D.Blaikie.
Hopefully I got it right this time: lifetime of initializer list ends
as with any expression, which make invalid the pattern:
ArrayRef<int> Arr = { 1, 2, 3, 4};
Just like StringRef, ArrayRef shouldn't be used to initialize local
variable but only as function argument.
Hans Wennborg [Thu, 10 Sep 2015 00:37:18 +0000 (00:37 +0000)]
Revert r247218: "Fix Clang-tidy misc-use-override warnings, other minor fixes"
Seems it broke the Polly build.
From http://lab.llvm.org:8011/builders/perf-x86_64-penryn-O3-polly-fast/builds/11687/steps/compile/logs/stdio:
In file included from /home/grosser/buildslave/perf-x86_64-penryn-O3-polly-fast/llvm.src/lib/TableGen/Record.cpp:14:0:
/home/grosser/buildslave/perf-x86_64-penryn-O3-polly-fast/llvm.src/include/llvm/TableGen/Record.h:369:3: error: looser throw specifier for 'virtual llvm::TypedInit::~TypedInit()'
/home/grosser/buildslave/perf-x86_64-penryn-O3-polly-fast/llvm.src/include/llvm/TableGen/Record.h:270:11: error: overriding 'virtual llvm::Init::~Init() noexcept (true)'
Piotr Padlewski [Wed, 9 Sep 2015 22:20:28 +0000 (22:20 +0000)]
Generating assumption loads of vptr after ctor call (fixed)
Generating call assume(icmp %vtable, %global_vtable) after constructor
call for devirtualization purposes.
For more info go to:
http://lists.llvm.org/pipermail/cfe-dev/2015-July/044227.html
Edit:
Fixed version because of PR24479.
After this patch got reverted because of ScalarEvolution bug (D12719)
Merged after John McCall big patch (Added Address).
David Majnemer [Wed, 9 Sep 2015 20:57:59 +0000 (20:57 +0000)]
[MS ABI] Don't crash on references to pointers to members in args
We know that a reference can always be dereferenced. However, we don't
always know the number of bytes if the reference's pointee type is
incomplete. This case was correctly handled but we didn't consider the
case where the type is complete but we cannot calculate its size for ABI
specific reasons. In this specific case, a member pointer's size is
available only under certain conditions.
[ARM] "cortex-r5f" and "cortex-m4f" are unknown names for clang.
The tests in test/CodeGen/arm-target-features.c are currently
passing but warning messages are suppressed. These tests are now
synchronized with the corresponding changes in Target Parser.
This patch will fix the regressions in clang caused by r247136
Introduce __builtin_nontemporal_store and __builtin_nontemporal_load.
Summary:
Currently clang provides no general way to generate nontemporal loads/stores.
There are some architecture specific builtins for doing so (e.g. in x86), but
there is no way to generate non-temporal store on, e.g. AArch64. This patch adds
generic builtins which are expanded to a simple store with '!nontemporal'
attribute in IR.
Revert "[Static Analyzer] BugReporter.cpp:2869: Assertion failed: !RemainingNodes.empty() && "No error node found in the trimmed graph""
This is making our internal build bot fail because it results in extra warnings being
emitted past what should be sink nodes. (There is actually an example of this in the
updated malloc.c test in the reverted commit.)
I'm working on a patch to fix the original issue by adding a new checker API to explicitly
create error nodes. This API will ensure that error nodes are always tagged in order to
prevent them from being reclaimed.
Adrian Prantl [Tue, 8 Sep 2015 20:41:52 +0000 (20:41 +0000)]
Module Debugging: Emit debug type information into clang ObjC modules.
When -fmodule-format is set to "obj", emit debug info for all types
declared in a module or referenced by a declaration into the module's
object file container.
This patch adds support for Objective-C types and methods.
Richard Smith [Tue, 8 Sep 2015 19:40:14 +0000 (19:40 +0000)]
[modules] Write the options records to a separate subblock rather than writing
them directly to the control block. These are fairly large, and in a build with
lots of modules / chained PCH, we don't need to read most of them. No
functionality change intended.
Adrian Prantl [Tue, 8 Sep 2015 19:20:27 +0000 (19:20 +0000)]
Module Debugging: Emit debug type information into clang modules.
When -fmodule-format is set to "obj", emit debug info for all types
declared in a module or referenced by a declaration into the module's
object file container.
Failing test highlighting no poisoning if dtor undeclared.
Summary:
If class or struct has not declared a destructor,
no destructor is emitted, and members are not poisoned
after destruction. This case highlights bug in current
implementation of use-after-dtor poisoning (detailed
in https://github.com/google/sanitizers/issues/596).
Jakub Kuderski [Tue, 8 Sep 2015 10:36:42 +0000 (10:36 +0000)]
findDominatingStoreToReturn in CGCall.cpp didn't check if a candidate store
instruction used the ReturnValue as pointer operand or value operand. This
led to wrong code gen - in later stages (load-store elision code) the found
store and its operand would be erased, causing ReturnValue to become a <badref>.
The patch adds a check that makes sure that ReturnValue is a pointer operand of
store instruction. Regression test is also added.
This fixes PR24386.
Differential Revision: http://reviews.llvm.org/D12400
Manuel Klimek [Tue, 8 Sep 2015 10:11:26 +0000 (10:11 +0000)]
Fix documentation of numSelectorArgs.
Currently, the documentation for numSelectorArgs includes an incorrect
example. It shows a case where an argument of 1 will match a property
getter, but a getter will be matched only when N == 0.
This diff corrects the documentation and adds a test for numSelectorArgs(0).
John McCall [Tue, 8 Sep 2015 08:05:57 +0000 (08:05 +0000)]
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
Apparently there are many cast kinds that may cause implicit pointer
arithmetic to happen. In light of this, the cast ignoring logic
introduced in r246877 has been changed to only ignore a small set of
cast kinds, and a test for this behavior has been added.
Thanks to Richard for catching this before it became a bug report. :)
Hal Finkel [Fri, 4 Sep 2015 21:49:21 +0000 (21:49 +0000)]
Don't crash on a self-alias declaration
We were crashing in CodeGen given input like this:
int self_alias(void) __attribute__((weak, alias("self_alias")));
such a self-alias is invalid, but instead of diagnosing the situation, we'd
proceed to produce IR for both the function declaration and the alias. Because
we already had a function named 'self_alias', the alias could not be named the
same thing, and so LLVM would pick a different name ('self_alias1' for example)
for that value. When we later called CodeGenModule::checkAliases, we'd look up
the IR value corresponding to the alias name, find the function declaration
instead, and then assert in a cast to llvm::GlobalAlias. The easiest way to prevent
this is simply to avoid creating the wrongly-named alias value in the first
place and issue the diagnostic there (instead of in checkAliases). We detect a
related cycle case in CodeGenModule::EmitAliasDefinition already, so this just
adds a second such check.
Even though the other test cases for this 'alias definition is part of a cycle'
diagnostic are in test/Sema/attr-alias-elf.c, I've added a separate regression
test for this case. This is because I can't add this check to
test/Sema/attr-alias-elf.c without disturbing the other test cases in that
file. In order to avoid construction of the bad IR values, this diagnostic
is emitted from within CodeGenModule::EmitAliasDefinition (and the relevant
declaration is not added to the Aliases vector). The other cycle checks are
done within the CodeGenModule::checkAliases function based on the Aliases
vector, called from CodeGenModule::Release. However, if there have been errors
earlier, HandleTranslationUnit does not call Release, and so checkAliases is
never called, and so none of the other diagnostics would be produced.
Richard Smith [Fri, 4 Sep 2015 21:44:32 +0000 (21:44 +0000)]
Fix crash on invalid if we can't find a suitable PCH file in a specified
directory, and our frontend action cares whether the frontend setup actually
succeeded.
- For all types, we would give up in a case such as:
__builtin_object_size((char*)&foo, N);
even if we could provide an answer to
__builtin_object_size(&foo, N);
We now provide the same answer for both of the above examples in all
cases.
- For type=1|3, we now support subobjects with unknown bases, as long
as the designator is valid.
Thanks to Richard Smith for the review + design planning.
Hans Wennborg [Fri, 4 Sep 2015 19:59:39 +0000 (19:59 +0000)]
Don't allow dllexport/import on static local variables
They might technically have external linkage, but it still doesn't make sense
for the user to try and export such variables. This matches MSVC's and MinGW's
behaviour.
Ed Schouten [Fri, 4 Sep 2015 16:07:39 +0000 (16:07 +0000)]
Put ext_implicit_lib_function_decl in ImplicitFunctionDeclare.
If we build with -Werror=implicit-function-declaration, only implicit
function declarations of non-library functions throw compiler errors.
For library functions, we only produce a warning. There is no way to
promote both of these cases to an error without promoting other
warnings.
It makes little sense to introduce an additional compiler flag just to
control this specific warning. In my opinion it should just be part of
the same group.
[OPENMP] Fix false diagnostic on instantiation-dependent exprs for atomic constructs.
Some of instantiation-dependent expressions could cause false diagnostic to be emitted about unsupported atomic constructs. Relaxed rules for detection of incorrect expressions.
[OPENMP] Fix for http://llvm.org/PR24674: assertion failed and and abort trap
Fix processing of shared variables with reference types in OpenMP constructs. Previously, if the variable was not marked in one of the private clauses, the reference to this variable was emitted incorrectly and caused an assertion later.
- Support multiple inheritance by poisoning after
member destructors are invoked, and before base
class destructors are invoked.
- Poison for virtual destructor and virtual bases.
- Repress dtor aliasing when sanitizing in dtor.
- CFE test for dtor aliasing, and repression of aliasing in dtor
code generation.
- Poison members on field-by-field basis, with collective poisoning
of trivial members when possible.
- Check msan flags and existence of fields, before dtor sanitizing,
and when determining if aliasing is allowed.
- Testing sanitizing bit fields.
Dan Gohman [Thu, 3 Sep 2015 22:51:53 +0000 (22:51 +0000)]
[WebAssembly] Initial WebAssembly support in clang
This implements basic support for compiling (though not yet assembling
or linking) for a WebAssembly target. Note that ABI details are not yet
finalized, and may change.
Thread safety analysis: the NO_THREAD_SAFETY_ANALYSIS attribute will now
disable checking of arguments to the function, which is done by
-Wthread-safety-reference.
Manuel Klimek [Thu, 3 Sep 2015 16:11:10 +0000 (16:11 +0000)]
[libclang] Return deduced type for auto type, not the one written in the source.
It used to work, but was accidentally broken by r179769.
The issue with decayed types was fixed by r190796.
So this patch partially reverts r179769, and adds more tests.
Oliver Stannard [Thu, 3 Sep 2015 12:40:58 +0000 (12:40 +0000)]
[ARM] Allow passing/returning of __fp16 arguments
The ACLE (ARM C Language Extensions) 2.0 allows the __fp16 type to be
used as a functon argument or return type (ACLE 1.1 did not).
The current public release of the AAPCS (2.09) states that __fp16 values
should be converted to single-precision before being passed or returned,
but AAPCS 2.10 (to be released shortly) changes this, so that they are
passed in the least-significant 16 bits of either a GPR (for base AAPCS)
or a single-precision register (for AAPCS-VFP). This does not change how
arguments are passed if they get passed on the stack.
This patch brings clang up to compliance with the latest versions of
both of these specs.
We can now set the __ARM_FP16_ARGS ACLE predefine, and we have always
been able to set the __ARM_FP16_FORMAT_IEEE predefine (we do not support
the alternative format).
Oliver Stannard [Thu, 3 Sep 2015 11:46:24 +0000 (11:46 +0000)]
Revert 246755 as it breaks buildbots
Original commit message:
[ARM] Allow passing/returning of __fp16 arguments
The ACLE (ARM C Language Extensions) 2.0 allows the __fp16 type to be
used as a functon argument or return type (ACLE 1.1 did not).
The current public release of the AAPCS (2.09) states that __fp16 values
should be converted to single-precision before being passed or returned,
but AAPCS 2.10 (to be released shortly) changes this, so that they are
passed in the least-significant 16 bits of either a GPR (for base AAPCS)
or a single-precision register (for AAPCS-VFP). This does not change how
arguments are passed if they get passed on the stack.
This patch brings clang up to compliance with the latest versions of
both of these specs.
We can now set the __ARM_FP16_ARGS ACLE predefine, and we have always
been able to set the __ARM_FP16_FORMAT_IEEE predefine (we do not support
the alternative format).
projects / clang / log