| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 296246
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
2nd attempt: the first was in r296231, but it had a use after lifetime
bug.
Clang has logic to lower certain conditional expressions directly into llvm
select instructions. However, it does not emit the correct profile counter
increment as it does this: it emits an unconditional increment of the counter
for the 'then branch', even if the value selected is from the 'else branch'
(this is PR32019).
That means, given the following snippet, we would report that "0" is selected
twice, and that "1" is never selected:
int f1(int x) {
return x ? 0 : 1;
^2 ^0
}
f1(0);
f1(1);
Fix the problem by using the instrprof_increment_step intrinsic to do the
proper increment.
llvm-svn: 296245
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(PR32019)"
This reverts commit r296231. It causes an assertion failure on 32-bit
machines
clang: /export/users/atombot/llvm/clang-atom-d525-fedora-rel/llvm/lib/IR/Instructions.cpp:263: void llvm::CallInst::init(llvm::FunctionType*, llvm::Value*, llvm::ArrayRef<llvm::Value*>, llvm::ArrayRef<llvm::OperandBundleDefT<llvm::Value*> >, const llvm::Twine&): Assertion `(i >= FTy->getNumParams() || FTy->getParamType(i) == Args[i]->getType()) && "Calling a function with a bad signature!"' failed.
llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/export/users/atombot/llvm/clang-atom-d525-fedora-rel/stage1/./bin/clang+0x1c5fbfa)
llvm::sys::RunSignalHandlers() (/export/users/atombot/llvm/clang-atom-d525-fedora-rel/stage1/./bin/clang+0x1c5dc7e)
SignalHandler(int) (/export/users/atombot/llvm/clang-atom-d525-fedora-rel/stage1/./bin/clang+0x1c5dde2)
__restore_rt (/lib64/libpthread.so.0+0x3f1d00efa0)
__GI_raise /home/glibctest/rpmbuild/BUILD/glibc-2.17-c758a686/signal/../nptl/sysdeps/unix/sysv/linux/raise.c:56:0
__GI_abort /home/glibctest/rpmbuild/BUILD/glibc-2.17-c758a686/stdlib/abort.c:92:0
__assert_fail_base /home/glibctest/rpmbuild/BUILD/glibc-2.17-c758a686/assert/assert.c:92:0
(/lib64/libc.so.6+0x3f1c82e622)
llvm::CallInst::init(llvm::FunctionType*, llvm::Value*, llvm::ArrayRef<llvm::Value*>, llvm::ArrayRef<llvm::OperandBundleDefT<llvm::Value*> >, llvm::Twine const&) (/export/users/atombot/llvm/clang-atom-d525-fedora-rel/stage1/./bin/clang+0x1804e3a)
clang::CodeGen::CodeGenPGO::emitCounterIncrement(clang::CodeGen::CGBuilderTy&, clang::Stmt const*, llvm::Value*) (/export/users/atombot/llvm/clang-atom-d525-fedora-rel/stage1/./bin/clang+0x1ec7891)
llvm-svn: 296234
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Clang has logic to lower certain conditional expressions directly into
llvm select instructions. However, it does not emit the correct profile
counter increment as it does this: it emits an unconditional increment
of the counter for the 'then branch', even if the value selected is from
the 'else branch' (this is PR32019).
That means, given the following snippet, we would report that "0" is
selected twice, and that "1" is never selected:
int f1(int x) {
return x ? 0 : 1;
^2 ^0
}
f1(0);
f1(1);
Fix the problem by using the instrprof_increment_step intrinsic to do
the proper increment.
llvm-svn: 296231
|
|
|
|
|
|
|
|
|
| |
Teach ubsan to diagnose remainder operations which have undefined
behavior due to signed overflow (e.g INT_MIN % -1).
Differential Revision: https://reviews.llvm.org/D29437
llvm-svn: 296214
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
C requires the operands of arithmetic expressions to be promoted if
their types are smaller than an int. Ubsan emits overflow checks when
this sort of type promotion occurs, even if there is no way to actually
get an overflow with the promoted type.
This patch teaches clang how to omit the superflous overflow checks
(addressing PR20193).
Testing: check-clang and check-ubsan.
Differential Revision: https://reviews.llvm.org/D29369
llvm-svn: 296213
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The goal of this is to fix a bug in modules where we'd merge
FunctionDecls that differed in their pass_object_size attributes. Since
we can overload on the presence of pass_object_size attributes, this
behavior is incorrect.
We don't represent `N` in `pass_object_size(N)` as part of
ExtParameterInfo, since it's an error to overload solely on the value of
N. This means that we have a bug if we have two modules that declare
functions that differ only in their pass_object_size attrs, like so:
// In module A, from a.h
void foo(char *__attribute__((pass_object_size(0))));
// In module B, from b.h
void foo(char *__attribute__((pass_object_size(1))));
// In module C, in main.c
#include "a.h"
#include "b.h"
At the moment, we'll merge the foo decls, when we should instead emit a
diagnostic about an invalid overload. We seem to have similar (silent)
behavior if we overload only on the return type of `foo` instead; I'll
try to find a good place to put a FIXME (or I'll just file a bug) soon.
This patch also fixes a bug where we'd not output the proper extended
parameter info for declarations with pass_object_size attrs.
llvm-svn: 296076
|
|
|
|
|
|
|
|
|
| |
Fix the fact that we don't assign profile counters to constructors in
classes with virtual bases, or constructors with variadic parameters.
Differential Revision: https://reviews.llvm.org/D30131
llvm-svn: 296062
|
|
|
|
|
|
|
| |
This is a preparation clean-up commit around the code that emits
block copy/dispose routines.
llvm-svn: 296054
|
|
|
|
| |
llvm-svn: 296034
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch makes use of the prefix/suffix ABI argument distinction that
was introduced in r295870, so that we now emit ExtParameterInfo at the
correct offset for member calls that have added ABI arguments. I don't
see a good way to test the generated param info, since we don't actually
seem to use it in CGFunctionInfo outside of Swift. Any
suggestions/thoughts for how to better test this are welcome. :)
This patch also fixes a small bug with inheriting constructors: if we
decide not to pass args into an base class ctor, we would still
generate ExtParameterInfo as though we did. The added test-case is for
that behavior.
llvm-svn: 296024
|
|
|
|
|
|
|
|
|
|
|
|
| |
CodeGens uses of @available into calls to the compiler-rt function
__isOSVersionAtLeast.
This commit is part of a feature that I proposed here:
http://lists.llvm.org/pipermail/cfe-dev/2016-July/049851.html
Differential revision: https://reviews.llvm.org/D27827
llvm-svn: 296015
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes an assertion failure in cases where we had expression
statements that declared variables nested inside of pass_object_size
args. Since we were emitting the same ExprStmt twice (once for the arg,
once for the @llvm.objectsize call), we were getting issues with
redefining locals.
This also means that we can be more lax about when we emit
@llvm.objectsize for pass_object_size args: since we're reusing the
arg's value itself, we don't have to care so much about side-effects.
llvm-svn: 295935
|
|
|
|
| |
llvm-svn: 295918
|
|
|
|
|
|
| |
This fixes a few assertion failures. Please see the added test case.
llvm-svn: 295894
|
|
|
|
| |
llvm-svn: 295874
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: We implement structured exception handling (SEH) by generating filter functions for functions that use exceptions. Currently, we use associative comdats to ensure that the filter functions are preserved if and only if the functions we generated them for are preserved. This can lead to problems when generating COFF objects - LLVM may decide to inline a function that uses SEH and remove its body, at which point we will end up with a comdat that COFF cannot represent. To avoid running into that situation, this change makes us not use associative comdats for SEH filter functions. We can still get the benefits we used the associative comdats for: we will always preserve filter functions we use, and dead stripping can eliminate the ones we don't use.
Reviewers: rnk, pcc, ruiu
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D30117
llvm-svn: 295872
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Meta: The ultimate goal is to teach ExtParameterInfo about
pass_object_size attributes. This is necessary for that, since our
ExtParameterInfo is a bit buggy in C++. I plan to actually make use of
this Prefix/Suffix info in the near future, but I like small
single-purpose changes. Especially when those changes are hard to
actually test...
At the moment, some of our C++-specific CodeGen pretends that ABIs can
only add arguments to the beginning of a function call. This isn't quite
correct: args can be appended to the end, as well. It hasn't mattered
much until now, since we seem to only use this "number of arguments
added" data when calculating the ExtParameterInfo to use when making a
CGFunctionInfo. Said ExtParameterInfo is currently only used for
ParameterABIs (Swift) and ns_consumed (ObjC).
So, this patch allows ABIs to indicate whether args they added were at
the beginning or end of an argument list. We can use this information to
emit ExtParameterInfos more correctly, though like said, that bit is
coming soon.
No tests since this is theoretically a nop.
llvm-svn: 295870
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The following code would crash clang:
void foo(unsigned *const __attribute__((pass_object_size(0))));
void bar(unsigned *i) { foo(i); }
This is because we were always selecting the version of
`@llvm.objectsize` that takes an i8* in CodeGen. Passing an i32* as an
i8* makes LLVM very unhappy.
(Yes, I'm surprised that this remained uncaught for so long, too. :) )
As an added bonus, we'll now also use the appropriate address space when
emitting @llvm.objectsize calls.
llvm-svn: 295805
|
|
|
|
|
|
|
|
|
|
| |
declaration declared using class template argument deduction.
Patch by Eric Fiselier (who is busy and asked me to commit this on his behalf)!
Differential Revision: https://reviews.llvm.org/D30082
llvm-svn: 295794
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: AddDiscriminator pass is only useful for sample pgo. This patch restricts AddDiscriminator to -fdebug-info-for-profiling so that it does not introduce unecessary debug size increases for non-sample-pgo builds.
Reviewers: dblaikie, aprantl
Reviewed By: dblaikie
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D30220
llvm-svn: 295764
|
|
|
|
| |
llvm-svn: 295763
|
|
|
|
| |
llvm-svn: 295527
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch teaches ubsan to insert exactly one null check for the 'this'
pointer per method/lambda.
Previously, given a load of a member variable from an instance method
('this->x'), ubsan would insert a null check for 'this', and another
null check for '&this->x', before allowing the load to occur.
Similarly, given a call to a method from another method bound to the
same instance ('this->foo()'), ubsan would a redundant null check for
'this'. There is also a redundant null check in the case where the
object pointer is a reference ('Ref.foo()').
This patch teaches ubsan to remove the redundant null checks identified
above.
Testing: check-clang, check-ubsan, and a stage2 ubsan build.
I also compiled X86FastISel.cpp with -fsanitize=null using
patched/unpatched clangs based on r293572. Here are the number of null
checks emitted:
-------------------------------------
| Setup | # of null checks |
-------------------------------------
| unpatched, -O0 | 21767 |
| patched, -O0 | 10758 |
-------------------------------------
Changes since the initial commit:
- Don't introduce any unintentional object-size or alignment checks.
- Don't rely on IRGen of C labels in the test.
Differential Revision: https://reviews.llvm.org/D29530
llvm-svn: 295515
|
|
|
|
|
|
|
|
|
|
|
| |
CodeGenFunction::EmitTypeCheck accepts a bool flag which controls
whether or not null checks are emitted. Make this a bit more flexible by
changing the bool to a SanitizerSet.
Needed for an upcoming change which deals with a scenario in which we
only want to emit null checks.
llvm-svn: 295514
|
|
|
|
|
|
|
|
| |
This reverts commit r295401. It breaks the ubsan self-host. It inserts
object size checks once per C++ method which fire when the structure is
empty.
llvm-svn: 295494
|
|
|
|
|
|
|
|
| |
than just treating them as FunctionDecls with a funny name.
No functionality change intended.
llvm-svn: 295491
|
|
|
|
|
|
|
|
|
| |
With tasks, the cancel may happen in another task. This has a different
region info which means that we can't find it here.
Differential Revision: https://reviews.llvm.org/D30091
llvm-svn: 295474
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This resolves a deadlock with the cancel directive when there is no explicit
cancellation point. In that case, the implicit barrier acts as cancellation
point. After removing the barrier after cancel, the now unmatched barrier for
the explicit cancellation point has to go as well.
This has probably worked before rL255992: With the calls for the explicit
barrier, it was sure that all threads passed a barrier before exiting.
Reported by Simon Convent and Joachim Protze!
Differential Revision: https://reviews.llvm.org/D30088
llvm-svn: 295473
|
|
|
|
|
|
| |
Updates for llvm r295465.
llvm-svn: 295466
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch teaches ubsan to insert exactly one null check for the 'this'
pointer per method/lambda.
Previously, given a load of a member variable from an instance method
('this->x'), ubsan would insert a null check for 'this', and another
null check for '&this->x', before allowing the load to occur.
Similarly, given a call to a method from another method bound to the
same instance ('this->foo()'), ubsan would a redundant null check for
'this'. There is also a redundant null check in the case where the
object pointer is a reference ('Ref.foo()').
This patch teaches ubsan to remove the redundant null checks identified
above.
Testing: check-clang and check-ubsan. I also compiled X86FastISel.cpp
with -fsanitize=null using patched/unpatched clangs based on r293572.
Here are the number of null checks emitted:
-------------------------------------
| Setup | # of null checks |
-------------------------------------
| unpatched, -O0 | 21767 |
| patched, -O0 | 10758 |
-------------------------------------
Changes since the initial commit: don't rely on IRGen of C labels in the
test.
Differential Revision: https://reviews.llvm.org/D29530
llvm-svn: 295401
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit r295391. It breaks this bot:
http://lab.llvm.org:8011/builders/clang-with-thin-lto-ubuntu/builds/1898
I need to not rely on labels in the IR test.
llvm-svn: 295396
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch teaches ubsan to insert exactly one null check for the 'this'
pointer per method/lambda.
Previously, given a load of a member variable from an instance method
('this->x'), ubsan would insert a null check for 'this', and another
null check for '&this->x', before allowing the load to occur.
Similarly, given a call to a method from another method bound to the
same instance ('this->foo()'), ubsan would a redundant null check for
'this'. There is also a redundant null check in the case where the
object pointer is a reference ('Ref.foo()').
This patch teaches ubsan to remove the redundant null checks identified
above.
Testing: check-clang and check-ubsan. I also compiled X86FastISel.cpp
with -fsanitize=null using patched/unpatched clangs based on r293572.
Here are the number of null checks emitted:
-------------------------------------
| Setup | # of null checks |
-------------------------------------
| unpatched, -O0 | 21767 |
| patched, -O0 | 10758 |
-------------------------------------
Differential Revision: https://reviews.llvm.org/D29530
llvm-svn: 295391
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch implements codegen for the reduction clause on
any teams construct for elementary data types. It builds
on parallel reductions on the GPU. Subsequently,
the team master writes to a unique location in a global
memory scratchpad. The last team to do so loads and
reduces this array to calculate the final result.
This patch emits two helper functions that are used by
the OpenMP runtime on the GPU to perform reductions across
teams.
Patch by Tian Jin in collaboration with Arpith Jacob
Reviewers: ABataev
Differential Revision: https://reviews.llvm.org/D29879
llvm-svn: 295335
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch implements codegen for the reduction clause on
any parallel construct for elementary data types. An efficient
implementation requires hierarchical reduction within a
warp and a threadblock. It is complicated by the fact that
variables declared in the stack of a CUDA thread cannot be
shared with other threads.
The patch creates a struct to hold reduction variables and
a number of helper functions. The OpenMP runtime on the GPU
implements reduction algorithms that uses these helper
functions to perform reductions within a team. Variables are
shared between CUDA threads using shuffle intrinsics.
An implementation of reductions on the NVPTX device is
substantially different to that of CPUs. However, this patch
is written so that there are minimal changes to the rest of
OpenMP codegen.
The implemented design allows the compiler and runtime to be
decoupled, i.e., the runtime does not need to know of the
reduction operation(s), the type of the reduction variable(s),
or the number of reductions. The design also allows reuse of
host codegen, with appropriate specialization for the NVPTX
device.
While the patch does introduce a number of abstractions, the
expected use case calls for inlining of the GPU OpenMP runtime.
After inlining and optimizations in LLVM, these abstractions
are unwound and performance of OpenMP reductions is comparable
to CUDA-canonical code.
Patch by Tian Jin in collaboration with Arpith Jacob
Reviewers: ABataev
Differential Revision: https://reviews.llvm.org/D29758
llvm-svn: 295333
|
|
|
|
| |
llvm-svn: 295323
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch implements codegen for the reduction clause on
any parallel construct for elementary data types. An efficient
implementation requires hierarchical reduction within a
warp and a threadblock. It is complicated by the fact that
variables declared in the stack of a CUDA thread cannot be
shared with other threads.
The patch creates a struct to hold reduction variables and
a number of helper functions. The OpenMP runtime on the GPU
implements reduction algorithms that uses these helper
functions to perform reductions within a team. Variables are
shared between CUDA threads using shuffle intrinsics.
An implementation of reductions on the NVPTX device is
substantially different to that of CPUs. However, this patch
is written so that there are minimal changes to the rest of
OpenMP codegen.
The implemented design allows the compiler and runtime to be
decoupled, i.e., the runtime does not need to know of the
reduction operation(s), the type of the reduction variable(s),
or the number of reductions. The design also allows reuse of
host codegen, with appropriate specialization for the NVPTX
device.
While the patch does introduce a number of abstractions, the
expected use case calls for inlining of the GPU OpenMP runtime.
After inlining and optimizations in LLVM, these abstractions
are unwound and performance of OpenMP reductions is comparable
to CUDA-canonical code.
Patch by Tian Jin in collaboration with Arpith Jacob
Reviewers: ABataev
Differential Revision: https://reviews.llvm.org/D29758
llvm-svn: 295319
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Removed ndrange_t as Clang builtin type and added
as a struct type in the OpenCL header.
Use type name to do the Sema checking in enqueue_kernel
and modify IR generation accordingly.
Review: D28058
Patch by Dmitry Borisenkov!
llvm-svn: 295311
|
|
|
|
|
|
|
|
|
|
|
| |
Destructor references are not modelled explicitly in the AST. This adds
checks for destructor calls due to variable definitions and temporaries.
If a dllimport function references a non-dllimport destructor, it must
not be emitted available_externally, as the referenced destructor might
live across the DLL boundary and isn't exported.
llvm-svn: 295258
|
|
|
|
|
|
|
|
| |
The function is used to check whether a type is a class with
non-dllimport destructor. It needs to look through typedefs and array
types.
llvm-svn: 295257
|
|
|
|
| |
llvm-svn: 295183
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
block or lambda.
This is a follow-up to r281682, which fixed a bug in computeBlockInfo
where the captured VarDecl's type, rather than the captured field type
of the enclosing lambda or block, was used to compute the layout of a
block.
This commit makes similar changes to enterBlockScope. This is necessary
to correctly determine whether a block capture requires cleanup.
rdar://problem/30388124
llvm-svn: 295034
|
|
|
|
|
|
| |
This bypasses integer sanitization checks which are redundant on the expression since it's been checked by Sema. Fixes a clang codegen assertion on "void test() { new int[0+1]{0}; }" when building with -fsanitize=signed-integer-overflow.
llvm-svn: 295006
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes https://bugs.llvm.org/show_bug.cgi?id=31932
Based on a patch by Roland McGrath
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D29843
llvm-svn: 294978
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D29309
llvm-svn: 294961
|
|
|
|
|
|
|
|
|
|
| |
Use # as the comment leader for AArch64 auto-release elision marker.
This is to keep it in sync with the value used in swift. When building
libdispatch for Linux AArch64, the auto-release elision marker was
emitted. However, ELF uses # as the comment leader while MachO accepts
both ; and #. Use the common marker for it instead.
llvm-svn: 294877
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Certain ARC runtime functions have an ABI contract of being forwarding.
Annotate the functions with the appropriate `returned` attribute on the
arguments. This hoists some of the runtime ABI contract information
into the frontend rather than the backend transformations.
The test adjustments are to mark the returned function parameter as
such. The minor change to the IR output is due to the fact that the
returned reference of the object causes it to extend the lifetime of the
object by returning an autoreleased return value. The result is that
the explicit objc_autorelease call is no longer formed, as autorelease
elision is now possible on the return.
llvm-svn: 294872
|
|
|
|
|
|
| |
objc_storeStrong does not return a value.
llvm-svn: 294855
|
|
|
|
|
|
| |
Adjust style before making more intrusive changes. NFC.
llvm-svn: 294854
|
|
|
|
| |
llvm-svn: 294740
|