I discovered a case where the old algorithm would crash. Instead of
trying to patch the algorithm, rewrite it. The new algorithm operates
in three phases:
1. Find all paths to the subobject with the vptr.
2. Remove paths which are subsets of other paths.
3. Select the best path where 'best' is defined as introducing the most
covariant overriders. If two paths introduce different overriders,
raise a diagnostic.
llvm-svn: 236444
If a class is absent from instantiation and is incomplete, instantiate it as
an incomplete class thus avoiding compiler crash.
This change fixes PR18653.
Differential Revision: http://reviews.llvm.org/D8281
llvm-svn: 236426
This reverts commit r236422, effectively reapplying r236419. ASan
helped me diagnose the problem: the non-leaking logic would free the
ASTConsumer before freeing Sema whenever `isCurrentASTFile()`, causing a
use-after-free in `Sema::~Sema()`.
This version unconditionally frees Sema and the ASTContext before
freeing the ASTConsumer. Without the fix, these were either being freed
before the ASTConsumer was freed or leaked after, but they were always
spiritually released so this isn't really a functionality change.
I ran all of check-clang with ASan locally this time, so I'm hoping
there aren't any more problems lurking.
Original commit message:
Try again to plug a leak that's been around since at least r128011
after coming across the FIXME. Nico Weber tried something similar
in r207065 but had to revert in r207070 due to a bot failure.
The build failure isn't visible anymore so I'm not sure what went
wrong. I'm doing this slightly differently -- when not
-disable-free I'm still resetting the members (just not leaking
them) -- so maybe it will work out this time? Tests pass locally,
anyway.
llvm-svn: 236424
This fixes errors that occur if a path to the default compiler has spaces or if an argument with spaces is given to compiler (e.g. via -I). (http://reviews.llvm.org/D9357)
llvm-svn: 236423
Try again to plug a leak that's been around since at least r128011 after
coming across the FIXME. Nico Weber tried something similar in r207065
but had to revert in r207070 due to a bot failure.
The build failure isn't visible anymore so I'm not sure what went wrong.
I'm doing this slightly differently -- when not -disable-free I'm still
resetting the members (just not leaking them) -- so maybe it will work
out this time? Tests pass locally, anyway.
llvm-svn: 236419
clang::MacroDefinition now models the currently-defined value of a macro. The
previous MacroDefinition type, which represented a record of a macro definition
directive for a detailed preprocessing record, is now called MacroDefinitionRecord.
llvm-svn: 236400
Using GetNumBytesInBuffer() assumes that the stream was not flushed between
the GetNumBytesInBuffer() calls, which may happen to be true or not,
depending on stream policy. tell() always reports the correct stream location.
Do note there are only two more uses of GetNumBytesInBuffer() in LLVM+clang, in
lib/MC/MCAsmStreamer.cpp and lib/Target/R600/InstPrinter/AMDGPUInstPrinter.cpp.
The former may be replacable by tell (needs testing) but while the later can
not be immediatly replaced by tell() as it uses the absolute value of
GetNumBytesInBuffer() rather than the real stream position. Both uses seems
to depend upon flush policy and thus may not work correctly depending upon the
stream behaviour.
Going forward, GetNumBytesInBuffer() should probably be protected, non-accessible
to raw_ostream clients.
llvm-svn: 236389
OriginalColumn might not be set, so fall back to Location and SourceMgr
in case it is missing. Also initialize end column in case the token is
multi line, but it's the ` token itself that starts the multi line.
Patch by Martin Probst, thank you!
llvm-svn: 236383
Parameters can have templated types and default values (= ...), which is
another location in which a template closer should be followed by
whitespace.
Patch by Martin Probst, thank you.
llvm-svn: 236382
This test verifies that we can detect when the inheritance paths are
ambiguous due to covariant thunks, ensuring we don't regress PR16759.
llvm-svn: 236381
The fact that PGO has a say in how these branch weights are determined
isn't interesting to most of CodeGen, so it makes more sense for this
API to be accessible via CodeGenFunction rather than CodeGenPGO.
llvm-svn: 236380
The underlying problem is that there is currently no way to run
ObjCARCContract from llvm bitcode which is required by ObjC ARC.
This fix the problem by always enable ObjCARCContract pass if
optimization is enabled. The ObjCARC Contract pass has almost no
overhead on code that is not using ARC.
llvm-svn: 236372
No functional change. This just makes it more obvious that the logic
in ComputeRegionCounts only depends on the counter map and local
state.
llvm-svn: 236370
This removes the RegionCounter class, which is only used as a helper
in teh ComputeRegionCounts stmt visitor. This class is just an extra
layer of abstraction that makes the code harder to follow at this
point, and removing it makes the logic quite a bit more direct.
llvm-svn: 236364
The MSVC ABI has a bug introduced by appending to the end of vftables
which come from virtual bases: covariant thunks introduces via
non-overlapping regions of the inheritance lattice both append to the
same slot in the vftable.
It is possible to generate correct vftables in cases where one node in
the lattice completely dominates the other on the way to the base with
the vfptr; in all other cases, we must raise a diagnostic in order to
prevent the illusion that we succeeded in laying out the vftable.
This fixes PR16759.
llvm-svn: 236354
A class might contain multiple ways of getting to a vbase, some of which
are virtual and other non-virtual. It may be the case that a
non-virtual base contains an override of a method in a vbase. This
means that we must carefully pick between a set of nvbases to determine
which is the best.
As a consequence, the findPathForVPtr algorithm is considerably simpler.
llvm-svn: 236353
This flag specifies that the normal visibility rules should be used even for
local submodules (submodules of the currently-being-built module). Thus names
will only be visible if a header / module that declares them has actually been
included / imported, and not merely because a submodule that happened to be
built earlier declared those names. This also removes the need to modularize
bottom-up: textually-included headers will be included into every submodule
that includes them, since their include guards will not leak between modules.
So far, this only governs visibility of macros, not of declarations, so is not
ready for real use yet.
llvm-svn: 236350
Cyclone actually supports all the goodies you'd expect to come with an AArch64
CPU, so it doesn't need its own clause. Also we should probably be testing
these clauses.
llvm-svn: 236349
The LHS was already being corrected before being set to ExprError when
the RHS is invalid, but when it was present the middle of a ternary
expression would be dropped in the error paths.
Fixes PR23350.
llvm-svn: 236347
It has no place there; it's not a property of the Module, and it makes
restoring the visibility set when we leave a submodule more difficult.
llvm-svn: 236300
This change is the third of 3 patches to add support for specifying
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.
This patch adds the necessary support to the clang frontend, and adds a
new test.
The compiler-rt and llvm parts are r236055 and r236288, respectively.
Patch by Teresa Johnson. Thanks!
llvm-svn: 236289
We were assigning the counter for the body of the loop to the loop
variable initialization for some reason here, but our tests completely
lacked coverage for range-for loops. This fixes that and makes the
logic generally more similar to the logic for a regular for.
llvm-svn: 236277
No functionality change; no-one inspects this field yet, and probably no-one
will ever inspect it in the "invalid" state, but ubsan could be unhappy about
this if such a DefInfo is copied.
llvm-svn: 236256
And thereby stop asserting.
In ObjC++ modes, we tentatively parse the lambda introducer twice: once
to disambiguate designators, which we also do in C++, and a second time
to disambiguate objc message expressions. During the second tentative
parse, the last cached token will be the annotation token we built in
the first parse. So use getLastLoc() to get the correct end location
for the rebuilt annotation.
llvm-svn: 236246
There can be multiple virtual bases which are on the path to a vfptr
when one vbase virtually inherits from another. We should prefer the
most derived virtual base which covariantly overrides a method in the
vfptr class; if we do not lengthen the path this way, we will end up
with too few vftable entries.
This fixes PR21073.
llvm-svn: 236239
For tasks codegen for private/firstprivate variables are different rather than for other directives.
1. Build an internal structure of privates for each private variable:
struct .kmp_privates_t. {
Ty1 var1;
...
Tyn varn;
};
2. Add a new field to kmp_task_t type with list of privates.
struct kmp_task_t {
void * shareds;
kmp_routine_entry_t routine;
kmp_int32 part_id;
kmp_routine_entry_t destructors;
.kmp_privates_t. privates;
};
3. Create a function with destructors calls for all privates after end of task region.
kmp_int32 .omp_task_destructor.(kmp_int32 gtid, kmp_task_t *tt) {
~Destructor(&tt->privates.var1);
...
~Destructor(&tt->privates.varn);
return 0;
}
4. Perform default initialization of all private fields (no initialization for POD data, default constructor calls for classes) + provide address of a destructor function after kmpc_omp_task_alloc() and before kmpc_omp_task() calls.
kmp_task_t *new_task = __kmpc_omp_task_alloc(ident_t *, kmp_int32 gtid, kmp_int32 flags, size_t sizeof_kmp_task_t, size_t sizeof_shareds, kmp_routine_entry_t *task_entry);
DefaultConstructor(new_task->privates.var1);
new_task->shareds.var1_ref = &new_task->privates.var1;
...
DefaultConstructor(new_task->privates.varn);
new_task->shareds.varn_ref = &new_task->privates.varn;
new_task->destructors = .omp_task_destructor.;
kmp_int32 __kmpc_omp_task(ident_t *, kmp_int32 gtid, kmp_task_t *new_task)
Differential Revision: http://reviews.llvm.org/D9322
llvm-svn: 236207
For proper codegen we need to capture variable in the OpenMP region. In loop-based directives loop control variables are private by default and they must be captured in this region. There was a problem with capturing of globals, used as lcv, as they was not marked as private by default.
Differential Revision: http://reviews.llvm.org/D9336
llvm-svn: 236201
Fixed initialization of 'single' region completion + changed type of the third argument of __kmpc_copyprivate() runtime function to size_t.
llvm-svn: 236198
a FileID corresponds to a real file or to a
memory buffer. The old method didn't work when
Clang was built Release, which meant it wasn't
a very good method at all.
llvm-svn: 236188
by erasing the soft-float target feature if the rest of the front
end added it because of defaults or the soft float option.
Add some testing for some of the targets that implement this hack.
llvm-svn: 236179
Modules builds fundamentally have a non-linear macro history. In the interest
of better source fidelity, represent the macro definition information
faithfully: we have a linear macro directive history within each module, and at
any point we have a unique "latest" local macro directive and a collection of
visible imported directives. This also removes the attendent complexity of
attempting to create a correct MacroDirective history (which we got wrong
in the general case).
No functionality change intended.
llvm-svn: 236176
Summary:
Hexagon is being updated, but there is not enough to pass these tests.
These sections are now on top of Colin's list.
Test Plan: Ran changes on hexagon-build-03.
Reviewers: colinl, rfoos
Reviewed By: rfoos
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D9356
llvm-svn: 236173
and as artificial local variables in the debug info.
This is a follow-up to r236059. We can't get rid of the local variables
entirely because the gdb buildbot depends on them, but we can mark them
as artificial while still emitting the correct debug info. As I learned
from review comments other compilers also follow this model.
A paired commit in LLVM temporarily relaxes the debug info verifier to
not check the integrity of DW_OP_bit_pieces of artificial variables.
rdar://problem/20730771
llvm-svn: 236125
LLVM r236120 renamed debug info IR constructs to use a `DI` prefix, now
that the `DIDescriptor` hierarchy has been gone for about a week. This
commit was generated using the rename-md-di-nodes.sh upgrade script
attached to PR23080, followed by running clang-format-diff.py on the
`lib/` portion of the patch.
llvm-svn: 236121
This issue was fixed elsewhere in r235396 in a more general way, hence these
changes no longer do anything. Keep the testcase however, to ensure that we
don't regress this for ARM.
llvm-svn: 236104
In Objective-C some style guides use a style where assignment operators are
aligned, in an effort to increase code readability. This patch adds an option
to the format library which allows this functionality. It is disabled by
default for all the included styles, so it must be explicitly enabled.
The option will change code such as:
- (void)method {
NSNumber *one = @1;
NSNumber *twentyFive = @25;
}
to:
- (void)method {
NSNumber *one = @1;
NSNumber *twentyFive = @25;
}
Patch by Matt Oakes. Thank you!
Accidentally reformatted all the tests...
llvm-svn: 236100
-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
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
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
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
ability to generate code that CodeGen likes. Test
cases can use this functionality by calling
// RUN: %clang_cc1 -emit-obj -o /dev/null -ast-merge %t.1.ast -ast-merge %t.2.ast %s
llvm-svn: 236011
Inclass initializer is instantiated in its own LocalInstantiationScope. It
causes problems when instantiating local classes - when instantiation scope
is searched for DeclContext of the field, the search fails. As a solution,
the instantiation scope of field initializer is combined with its outer
scope.
This patch fixes PR23194.
Differential Revision: http://reviews.llvm.org/D9258
llvm-svn: 236005
When creating a global variable with a type of a struct with bitfields, we must
forcibly set the alignment of the global from the RecordDecl. We must do this so
that the proper bitfield alignment makes its way down to LLVM, since clang will
mangle the bitfields into one large type.
llvm-svn: 235976
Embed UBSan runtime into TSan and MSan runtimes in the same as we do
in ASan. Extend UBSan test suite to also run tests for these
combinations.
llvm-svn: 235953
the active module macros at the point of definition, rather than reconstructing
it from the macro history. No functionality change intended.
llvm-svn: 235941
This makes sure that the front end is specific about what they're expecting
the backend to produce. Update a FIXME with the idea that the target-features
could be more precise using backend knowledge.
llvm-svn: 235936
For now tsan_cxx and msan_cxx contain only operator new/delete
replacements. In the future, when we add support for running UBSan+TSan
and UBSan+MSan, they will also contain bits ubsan_cxx runtime.
llvm-svn: 235924
Previously we'd try to perform checks on the captures from the middle of
parsing the lambda's body, at the point where we detected that a variable
needed to be captured. This was wrong in a number of subtle ways. In
PR23334, we couldn't correctly handle the list of potential odr-uses
resulting from the capture, and our attempt to recover from that resulted
in a use-after-free.
We now defer building the initialization expression until we leave the lambda
body and return to the enclosing context, where the initialization does the
right thing. This patch only covers lambda-expressions, but we should apply
the same change to blocks and captured statements too.
llvm-svn: 235921
During device-side CUDA compilation clang currently complains about
all TLS variables, regardless of whether they are __host__ or
__device__.
This patch suppresses "TLS unsupported" errors for host variables
during device compilation and for device variables during host
compilation.
Differential Revision: http://reviews.llvm.org/D9269
llvm-svn: 235907
Currently clang emits file-scope asm during *both* host and device
compilation modes which is usually a wrong thing to do.
There's no way to attach any attribute to an __asm statement, so
there's no way to differentiate between host-side and device-side
file-scope asm. This patch makes clang to match nvcc behavior and
emit file-scope-asm only during host-side compilation.
Differential Revision: http://reviews.llvm.org/D9270
llvm-svn: 235905
NMake is a Make-like builder that comes with Microsoft Visual Studio.
Jom (https://wiki.qt.io/Jom) is an NMake-compatible build tool.
Dependency files for NMake/Jom need to use double-quotes to wrap
filespecs containing special characters, instead of the backslash
escapes that GNU Make wants.
Adds the -MV option, which specifies to use double-quotes as needed
instead of backslash escapes when writing the dependency file.
Differential Revision: http://reviews.llvm.org/D9260
llvm-svn: 235903
This was a bug in r218285 that prevented us from seeing subsequent
virtual bases in the class hierarchy, leading to crashes later.
Also add some comments to this function, now that we better understand
what it's trying to do.
Fixes PR21062 and PR21064.
llvm-svn: 235899
Emit the following code for 'taskwait' directive within tied task:
call i32 @__kmpc_omp_taskwait(<loc>, i32 <thread_id>);
Differential Revision: http://reviews.llvm.org/D9245
llvm-svn: 235836
Emit a code for reduction clause. Next code should be emitted for reductions:
static kmp_critical_name lock = { 0 };
void reduce_func(void *lhs[<n>], void *rhs[<n>]) {
*(Type0*)lhs[0] = ReductionOperation0(*(Type0*)lhs[0], *(Type0*)rhs[0]);
...
*(Type<n>-1*)lhs[<n>-1] =
ReductionOperation<n>-1(*(Type<n>-1*)lhs[<n>-1],
*(Type<n>-1*)rhs[<n>-1]);
}
...
void *RedList[<n>] = {&<RHSExprs>[0], ..., &<RHSExprs>[<n>-1]};
switch (__kmpc_reduce{_nowait}(<loc>, <gtid>, <n>, sizeof(RedList), RedList, reduce_func, &<lock>)) {
case 1:
<LHSExprs>[0] = ReductionOperation0(*<LHSExprs>[0], *<RHSExprs>[0]);
...
<LHSExprs>[<n>-1] = ReductionOperation<n>-1(*<LHSExprs>[<n>-1], *<RHSExprs>[<n>-1]);
__kmpc_end_reduce{_nowait}(<loc>, <gtid>, &<lock>);
break;
case 2:
Atomic(<LHSExprs>[0] = ReductionOperation0(*<LHSExprs>[0], *<RHSExprs>[0]));
...
Atomic(<LHSExprs>[<n>-1] = ReductionOperation<n>-1(*<LHSExprs>[<n>-1], *<RHSExprs>[<n>-1]));
break;
default:;
}
Reduction variables are a kind of a private variables, they have private copies, but initial values are chosen in accordance with the reduction operation.
If sections directive has only single section, then original shared variables are used instead with barrier at the end of the directive.
Differential Revision: http://reviews.llvm.org/D9242
llvm-svn: 235835
#pragma omp sections lastprivate(<var>)
<BODY>;
This construct is translated into something like:
<last_iter> = alloca i32
<init for lastprivates>;
<last_iter> = 0
; No initializer for simple variables or a default constructor is called for objects.
; For arrays perform element by element initialization by the call of the default constructor.
...
OMP_FOR_START(...,<last_iter>, ..); sets <last_iter> to 1 if this is the last iteration.
<BODY>
...
OMP_FOR_END
if (<last_iter> != 0) {
<final copy for lastprivate>; Update original variable with the lastprivate value.
}
call __kmpc_cancel_barrier() ; an implicit barrier to avoid possible data race.
If there is only one section, there is no special code generation, original shared variables are used + barrier is emitted at the end of the directive.
Differential Revision: http://reviews.llvm.org/D9240
llvm-svn: 235834
If there are 2 or more sections in a 'section' directive the following code is generated:
<default init for privates>
@__kmpc_for_static_init_4();
<BODY for sections directive>
@__kmpc_for_static_fini()
If there is only one section, the following code is generated:
if (@__kmpc_single()) {
<default init for privates>
@__kmpc_end_single();
}
Differential Revision: http://reviews.llvm.org/D9239
llvm-svn: 235833
Emit the following code for 'single' directive with 'private' clause:
if (@__kmpc_single()) {
<default init for privates>
@__kmpc_end_single();
}
Differential Revision: http://reviews.llvm.org/D9238
llvm-svn: 235832
We could probably make this work if we cared enough. However, we are
far outside any language rules at this point.
This fixes PR21834.
llvm-svn: 235818
VerifyBitField must be called if we are to form a bitfield FieldDecl.
We will not verify the bitfield if the decl is known to be malformed in
other ways; pretend that we don't have a bitfield if this happens.
llvm-svn: 235816
Fixes rdar://20621065.
A more elegant fix would preclude this case by defining the
rules such that zero-size classes are always formally empty.
I believe the only extensions which create zero-size classes
right now are flexible arrays and zero-length arrays; it's
not abstractly unreasonable to say that those don't count
as members for the purposes of emptiness, just as zero-width
bitfields don't count. But that's an ABI-affecting change
and requires further discussion; in the meantime, let's not
assert / miscompile.
llvm-svn: 235815
Don't assume it's always is. This prevents a crash in Sema while
trying to merge return type for a builtin w/out function prototype.
PR: 23086
Differential Revision: http://reviews.llvm.org/D9235
Reviewed by: rsmith
llvm-svn: 235806
This fixes a crash when we're emitting coverage and a macro appears
between two binary conditional operators, ie, "foo ?: MACRO ?: bar",
and fixes the interaction of macros and conditional operators in
general.
llvm-svn: 235793
Before this patch, passing a non-existent absolute path to clang-cl would cause
stat'ing of impossible paths. For example, `clang-cl -c d:\adsfasdf.txt` would
cause a stat of
C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\LIBd:\asdfadsf.cc
llvm-svn: 235787
Emit the following code for 'single' directive with 'firtstprivate' clause:
if (@__kmpc_single()) {
<init for firstprivates>
@__kmpc_end_single();
}
@__kmpc_cancel_barrier(); // To avoid data race in firstprivate init
Differential Revision: http://reviews.llvm.org/D9223
llvm-svn: 235694
Runtime function for 'copyprivate' directive generates implicit barriers, so no need to emit it.
Differential Revision: http://reviews.llvm.org/D9215
llvm-svn: 235692
If there are 2 or more sections in a 'section' directive the following code is generated:
<init for firstprivates>
@__kmpc_cancel_barrier();// To avoid data race in firstprivate init
@__kmpc_for_static_init_4();
<BODY for sections directive>
@__kmpc_for_static_fini()
If there is only one section, the following code is generated:
if (@__kmpc_single()) {
<init for firstprivates>
@__kmpc_end_single();
}
@__kmpc_cancel_barrier(); // To avoid data race in firstprivate init
Differential Revision: http://reviews.llvm.org/D9214
llvm-svn: 235691
The RegionCounter type does a lot of legwork, but most of it is only
meaningful within the implementation of CodeGenPGO. The uses elsewhere
in CodeGen generally just want to increment or read counters, so do
that directly.
llvm-svn: 235664
Previously we'd defer this determination until writing the AST, which doesn't
allow us to use this information when building other submodules of the same
module. This change also allows us to use a uniform mechanism for writing
module macro records, independent of whether they are local or imported.
llvm-svn: 235614
In r235553, Clang started emitting lifetime markers more often. This
caused false negative in MSan, because MSan only poisons all allocas
once at function entry. Eventually, MSan should poison allocas at
lifetime start and probably also lifetime end, but until then, let's not
emit markers that aren't going to be useful.
llvm-svn: 235613
Adds codegen for 'atomic capture' constructs with the following forms of expressions/statements:
v = x binop= expr;
v = x++;
v = ++x;
v = x--;
v = --x;
v = x = x binop expr;
v = x = expr binop x;
{v = x; x = binop= expr;}
{v = x; x++;}
{v = x; ++x;}
{v = x; x--;}
{v = x; --x;}
{x = x binop expr; v = x;}
{x binop= expr; v = x;}
{x++; v = x;}
{++x; v = x;}
{x--; v = x;}
{--x; v = x;}
{x = x binop expr; v = x;}
{x = expr binop x; v = x;}
{v = x; x = expr;}
If x and expr are integer and binop is associative or x is a LHS in a RHS of the assignment expression, and atomics are allowed for type of x on the target platform atomicrmw instruction is emitted.
Otherwise compare-and-swap sequence is emitted.
Update of 'v' is not required to be be atomic with respect to the read or write of the 'x'.
bb:
...
atomic load <x>
cont:
<expected> = phi [ <x>, label %bb ], [ <new_failed>, %cont ]
<desired> = <expected> binop <expr>
<res> = cmpxchg atomic &<x>, desired, expected
<new_failed> = <res>.field1;
br <res>field2, label %exit, label %cont
exit:
atomic store <old/new x>, <v>
...
Differential Revision: http://reviews.llvm.org/D9049
llvm-svn: 235573
Type backreferences for arguments use the DecayedType's original type.
Because of this, arguments with the same canonical type with the same
mangling would not backreference each other if one was a
ConstantArrayType while the other was an IncompleteArrayType. Solve
this by canonicalizing the ConstantArrayType to a suitable
IncompleteArrayType.
This fixes PR23325.
llvm-svn: 235572
Summary:
Make sure signed overflow in "x--" is checked with
llvm.ssub.with.overflow intrinsic and is reported as:
"-2147483648 - 1 cannot be represented in type 'int'"
instead of:
"-2147483648 + -1 cannot be represented in type 'int'"
, like we do for unsigned overflow.
Test Plan: clang + compiler-rt regression test suite
Reviewers: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D8236
llvm-svn: 235568
We try to use the member variable "FuncName" here, but we've also used
that name as a parameter. This ends with us getting the length of the
function name wrong when we generate the coverage data.
llvm-svn: 235565
These extra endcatch markers aren't helping identify regions to outline,
so let's get rid of them. LLVM outlines (more or less) from begincatch
to endcatch. Any unwind edge from an enclosed invoke is a transition to
a new exception handler, which has it's own outlining markers.
llvm-svn: 235562
This reverts commit r234700. It turns out that the lifetime markers
were not the cause of Chromium failing but a bug which was uncovered by
optimizations exposed by the markers.
llvm-svn: 235553
Otherwise -fno-omit-frame-pointer and other flags like it aren't
applied.
Basic idea taken from Gao's patch, thanks!
Differential Revision: http://reviews.llvm.org/D9203
llvm-svn: 235537
If condition evaluates to true, the code executes task by calling @__kmpc_omp_task() runtime function.
If condition evaluates to false, the code executes serial version of the code by executing the following code:
call void @__kmpc_omp_task_begin_if0(<loc>, <threadid>, <task_t_ptr, returned by @__kmpc_omp_task_alloc()>);
proxy_task_entry(<gtid>, <task_t_ptr, returned by @__kmpc_omp_task_alloc()>);
call void @__kmpc_omp_task_complete_if0(<loc>, <threadid>, <task_t_ptr, returned by @__kmpc_omp_task_alloc()>);
Also it checks if the condition is constant and if it is constant it evaluates its value and then generates either parallel version of the code (if the condition evaluates to true), or the serial version of the code (if the condition evaluates to false).
Differential Revision: http://reviews.llvm.org/D9143
llvm-svn: 235507
This patch generates helper variables which used as a private copies of the corresponding original variables inside an OpenMP 'for' directive. These generated variables are initialized by default (with the default constructor, if any). In OpenMP region references to original variables are replaced by the references to these private helper variables.
Differential Revision: http://reviews.llvm.org/D9106
llvm-svn: 235503
Patch fixes bugs in codegen for loops with unsigned counters and zero trip count. Previously preconditions for all loops were built using logic (Upper - Lower) > 0. But if the loop is a loop with zero trip count, then Upper - Lower is < 0 only for signed integer, for unsigned we're running into an underflow situation.
In this patch we're using original Lower<Upper condition to check that loop body can be executed at least once. Also this allows to skip code generation for loops, if it is known that preconditions for the loop are always false.
Differential Revision: http://reviews.llvm.org/D9103
llvm-svn: 235500
Add codegen for 'ordered' directive:
__kmpc_ordered(ident_t *, gtid);
<associated statement>;
__kmpc_end_ordered(ident_t *, gtid);
Also for 'for' directives with the dynamic scheduling and an 'ordered' clause added a call to '__kmpc_dispatch_fini_(4|8)[u]()' function after increment expression for loop control variable:
while(__kmpc_dispatch_next(&LB, &UB)) {
idx = LB;
while (idx <= UB) { BODY; ++idx;
__kmpc_dispatch_fini_(4|8)[u](); // For ordered loops only.
} // inner loop
}
Differential Revision: http://reviews.llvm.org/D9070
llvm-svn: 235496
For example, a function taking a parameter with internal linkage will
itself have internal linkage since it cannot be called outside the
translation unit.
Differential Revision: http://reviews.llvm.org/D9182
llvm-svn: 235471
David Majnemer