| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
Return false for swifterror support until the backend is fixed.
llvm-svn: 317589
|
|
|
|
|
|
|
|
| |
macros that just pass the right comparison predicate value to the regular cmp intrinsic. Remove mask cmpeq/cmpgt builtins that are now unused.
This shortens the intrinsic headers a little and allows us to get rid of the cmpeq and cmpgt handling from CGBuiltin.cpp.
llvm-svn: 317506
|
|
|
|
|
|
|
|
| |
This corresponds to LLVM commiti r317488:
If that commit is reverted, this commit will also need to be reverted.
llvm-svn: 317489
|
|
|
|
|
|
|
|
|
|
|
| |
GNU frontends don't have options like /MT, /MD
This fixes a few link error regressions with libc++ and libc++abi
Reviewers: rnk, mstorsjo, compnerd
Differential Revision: https://reviews.llvm.org/D33620
llvm-svn: 317398
|
|
|
|
|
|
|
|
| |
class definitions in codegen.
If an explicit specialization has a static data member, it may be a definition and we may need to register it for emission.
llvm-svn: 317296
|
|
|
|
|
|
|
| |
The compiler may crash under some conditions if the getInvokeDest() is
used, but later it is not used. Fixed this problem in OpenMP.
llvm-svn: 317227
|
|
|
|
|
|
|
| |
If the thread id is requested in windows mode within funclets, we may
generate incorrect function call that could lead to broken codegen.
llvm-svn: 317208
|
|
|
|
|
|
|
| |
Fix a typo in the comment, reorder to ensure that the ordering matches
across the ObjC/ObjC++ cases. NFCI.
llvm-svn: 317146
|
|
|
|
|
|
|
|
|
| |
The cloning happens before all metadata nodes are resolved. Prevent the value
mapper from running into unresolved or temporary MD nodes.
Differential Revision: https://reviews.llvm.org/D39396
llvm-svn: 317047
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This change allows generalizing pointers in type signatures used for
cfi-icall by enabling the -fsanitize-cfi-icall-generalize-pointers flag.
This works by 1) emitting an additional generalized type signature
metadata node for functions and 2) llvm.type.test()ing for the
generalized type for translation units with the flag specified.
This flag is incompatible with -fsanitize-cfi-cross-dso because it would
require emitting twice as many type hashes which would increase artifact
size.
Reviewers: pcc, eugenis
Reviewed By: pcc
Subscribers: kcc
Differential Revision: https://reviews.llvm.org/D39358
llvm-svn: 317044
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The LLVM sqrt intrinsic definition changed with:
D28797
...so we don't have to use any relaxed FP settings other than errno handling.
This patch sidesteps a question raised in PR27435:
https://bugs.llvm.org/show_bug.cgi?id=27435
Is a programmer using __builtin_sqrt() invoking the compiler's intrinsic definition of sqrt or the mathlib definition of sqrt?
But we have an answer now: the builtin should match the behavior of the libm function including errno handling.
Differential Revision: https://reviews.llvm.org/D39204
llvm-svn: 317031
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch fixes various places in clang to propagate may-alias
TBAA access descriptors during construction of lvalues, thus
eliminating the need for the LValueBaseInfo::MayAlias flag.
This is part of D38126 reworked to be a separate patch to
simplify review.
Differential Revision: https://reviews.llvm.org/D39008
llvm-svn: 316988
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For non-zero alloca addr space, alloca is usually casted to default addr
space immediately.
For non-vla, alloca is inserted at AllocaInsertPt, therefore the addr
space cast should also be insterted at AllocaInsertPt. However,
for vla, alloca is inserted at the current insertion point of IRBuilder,
therefore the addr space cast should also inserted at the current
insertion point of IRBuilder.
Currently clang always insert addr space cast at AllocaInsertPt, which
causes invalid IR.
This patch fixes that.
Differential Revision: https://reviews.llvm.org/D39374
llvm-svn: 316909
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D39177
llvm-svn: 316896
|
|
|
|
|
|
|
|
| |
I noticed a few usages of llvm::join that were using
begin/end rather than just the range version. This patch
just replaces those.
llvm-svn: 316784
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Craig noticed that CodeGen wasn't properly ignoring the
values sent to the target attribute. This patch ignores
them.
This patch also sets the 'default' for this checking to
'supported', since only X86 has implemented the support
for checking valid CPU names and Feature Names.
One test was changed to i686, since it uses a lakemont,
which would otherwise be prohibited in x86_64.
Differential Revision: https://reviews.llvm.org/D39357
llvm-svn: 316783
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes an assertion failure when ivar is a struct containing incomplete
array. Also completes support for direct flexible array members.
rdar://problem/21054495
Reviewers: rjmccall, theraven
Reviewed By: rjmccall
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D38774
llvm-svn: 316723
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of only setting a non-zero debug location on the return
instruction in *_helper_block functions, set a proper location on all
instructions within these functions. Pick the start location of the
block literal expr for maximum clarity.
The debugger does not step into *_helper_block functions during normal
single-stepping because we mark their parameters as artificial. This is
what we want (the functions are implicitly generated and uninteresting
to most users). The stepping behavior is unchanged by this patch.
rdar://32907581
Differential Revision: https://reviews.llvm.org/D39310
llvm-svn: 316704
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The exisiting code goes out of its way to put block parameters into an
alloca only at -O0, and then describes the funciton argument with a
dbg.declare, which is undocumented in the LLVM-CFE contract and does
not actually behave as intended after LLVM r642022.
This patch just generates the alloca unconditionally, the mem2reg pass
will eliminate it at -O1 and up anyway and points the dbg.declare to
the alloca as intended (which mem2reg will then correctly rewrite into
a dbg.value).
This reapplies r316684 with some dead code removed.
rdar://problem/35043980
Differential Revision: https://reviews.llvm.org/D39305
llvm-svn: 316689
|
|
|
|
|
|
|
|
| |
parameters."
This reverts commit r316684 while investigating buildbot breakage.
llvm-svn: 316686
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The exisiting code goes out of its way to put block parameters into an
alloca only at -O0, and then describes the funciton argument with a
dbg.declare, which is undocumented in the LLVM-CFE contract and does
not actually behave as intended after LLVM r642022.
This patch just generates the alloca unconditionally, the mem2reg pass
will eliminate it at -O1 and up anyway and points the dbg.declare to
the alloca as intended (which mem2reg will then correctly rewrite into
a dbg.value).
rdar://problem/35043980
Differential Revision: https://reviews.llvm.org/D39305
llvm-svn: 316684
|
|
|
|
|
|
|
|
|
| |
Darwin uses char * for the variadic list type (va_list). We use the PPC
SVR4 ABI for PPC, which uses a structure type for the va_list. When
constructing the GEP, we would fail due to the incorrect handling for
the va_list. Correct this to use the right type.
llvm-svn: 316599
|
|
|
|
|
|
|
|
| |
Ensure that we check the ivar containing decl for the DLL storage
attribute rather than the ivar itself as the dll storage is associated
to the interface decl not the ivar decl.
llvm-svn: 316545
|
|
|
|
|
|
|
| |
Fixed passing of VLAs and variably-modified types to outlined functions.
Synchronized passing with the types codegen.
llvm-svn: 316488
|
|
|
|
|
|
|
|
|
|
|
|
| |
Builder save/restores insertion pointer when emitting addr space cast
for alloca, but does not save/restore debug loc, which causes verifier
failure for certain call instructions.
This patch fixes that.
Differential Revision: https://reviews.llvm.org/D39069
llvm-svn: 316484
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In some cases the compiler can deduce the length of an array section
as constants. With this information, VLAs can be avoided in place of
a constant sized array or even a scalar value if the length is 1.
Example:
int a[4], b[2];
pragma omp parallel reduction(+: a[1:2], b[1:1])
{ }
For chained array sections, this optimization is restricted to cases
where all array sections except the last have a constant length 1.
This trivially guarantees that there are no holes in the memory region
that needs to be privatized.
Example:
int c[3][4];
pragma omp parallel reduction(+: c[1:1][1:2])
{ }
This relands commit r316229 that I reverted in r316235 because it
failed on some bots. During investigation I found that this was because
Clang and GCC evaluate the two arguments to emplace_back() in
ReductionCodeGen::emitSharedLValue() in a different order, hence
leading to a different order of generated instructions in the final
LLVM IR. Fix this by passing in the arguments from temporary variables
that are evaluated in a defined order.
Differential Revision: https://reviews.llvm.org/D39136
llvm-svn: 316362
|
|
|
|
|
|
|
|
| |
variable
Differential Revision: https://reviews.llvm.org/D39184
llvm-svn: 316353
|
|
|
|
|
|
|
|
|
|
| |
This breaks at least two buildbots:
http://lab.llvm.org:8011/builders/clang-cmake-x86_64-avx2-linux/builds/1175
http://lab.llvm.org:8011/builders/clang-atom-d525-fedora-rel/builds/10478
This reverts commit r316229 during local investigation.
llvm-svn: 316235
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In some cases the compiler can deduce the length of an array section
as constants. With this information, VLAs can be avoided in place of
a constant sized array or even a scalar value if the length is 1.
Example:
int a[4], b[2];
pragma omp parallel reduction(+: a[1:2], b[1:1])
{ }
For chained array sections, this optimization is restricted to cases
where all array sections except the last have a constant length 1.
This trivially guarantees that there are no holes in the memory region
that needs to be privatized.
Example:
int c[3][4];
pragma omp parallel reduction(+: c[1:1][1:2])
{ }
Differential Revision: https://reviews.llvm.org/D39136
llvm-svn: 316229
|
|
|
|
|
|
|
|
|
|
| |
Resolves:
Fatal error: Offset not zero at the point of scalar access.
http://llvm.org/PR34992
Differential Revision: https://reviews.llvm.org/D39083
llvm-svn: 316211
|
|
|
|
|
|
|
|
| |
In function GetIntrinsic, not all types are covered. Types double and long long are missed, type long is wrongly treated same as int, it should be same as long long. These problems cause compiler crashes when compiling code in PR31161. This patch fixed the problem.
Differential Revision: https://reviews.llvm.org/D38820
llvm-svn: 316179
|
|
|
|
| |
llvm-svn: 316165
|
|
|
|
|
|
|
|
| |
If the variables is boolean and we generating inner function with real
types, the codegen may crash because of not loading boolean value from
memory.
llvm-svn: 316011
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently clang assumes the temporary variables emitted during
codegen of atomic builtins have address space 0, which
is not true for target triple amdgcn---amdgiz and causes invalid
bitcasts.
This patch fixes that.
Differential Revision: https://reviews.llvm.org/D38966
llvm-svn: 316000
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The main change is that now we generate TBAA info before
constructing the resulting lvalue instead of constructing lvalue
with some default TBAA info and fixing it as necessary
afterwards. We also keep the TBAA info close to lvalue base info,
which is supposed to simplify their future merging.
This patch should not bring in any functional changes.
This is part of D38126 reworked to be a separate patch to
simplify review.
Differential Revision: https://reviews.llvm.org/D38947
llvm-svn: 315989
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch addresses the rest of the cases where we pass lvalue
base info, but do not provide corresponding TBAA info.
This patch should not bring in any functional changes.
This is part of D38126 reworked to be a separate patch to make
reviewing easier.
Differential Revision: https://reviews.llvm.org/D38945
llvm-svn: 315986
|
|
|
|
|
|
|
|
| |
base info
Differential Revision: https://reviews.llvm.org/D38796
llvm-svn: 315984
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A trailing deferred region isn't necessary in a function that ends with
this pattern:
...
else {
...
return;
}
Special-case this pattern so that the closing curly brace of the
function isn't marked as uncovered. This issue came up in PR34962.
llvm-svn: 315982
|
|
|
|
|
|
|
|
|
|
| |
This makes it possible to view sub-line region counts for the l.h.s of
&& and || expressions in coverage reports.
It also fixes PR33465, which shows an example of incorrect coverage
output for an assignment statement containing '||'.
llvm-svn: 315979
|
|
|
|
|
|
|
|
| |
Currently all the consecutive bitfields are wrapped as a large integer unless there is unamed zero sized bitfield in between. The patch provides an alternative manner which makes the bitfield to be accessed as separate memory location if it has legal integer width and is naturally aligned. Such separate bitfield may split the original consecutive bitfields into subgroups of consecutive bitfields, and each subgroup will be wrapped as an integer. Now This is all controlled by an option -ffine-grained-bitfield-accesses. The alternative of bitfield access manner can improve the access efficiency of those bitfields with legal width and being aligned, but may reduce the chance of load/store combining of other bitfields, so it depends on how the bitfields are defined and actually accessed to choose when to use the option. For now the option is off by default.
Differential revision: https://reviews.llvm.org/D36562
llvm-svn: 315915
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Convert clang::LangAS to a strongly typed enum
Currently both clang AST address spaces and target specific address spaces
are represented as unsigned which can lead to subtle errors if the wrong
type is passed. It is especially confusing in the CodeGen files as it is
not possible to see what kind of address space should be passed to a
function without looking at the implementation.
I originally made this change for our LLVM fork for the CHERI architecture
where we make extensive use of address spaces to differentiate between
capabilities and pointers. When merging the upstream changes I usually
run into some test failures or runtime crashes because the wrong kind of
address space is passed to a function. By converting the LangAS enum to a
C++11 we can catch these errors at compile time. Additionally, it is now
obvious from the function signature which kind of address space it expects.
I found the following errors while writing this patch:
- ItaniumRecordLayoutBuilder::LayoutField was passing a clang AST address
space to TargetInfo::getPointer{Width,Align}()
- TypePrinter::printAttributedAfter() prints the numeric value of the
clang AST address space instead of the target address space.
However, this code is not used so I kept the current behaviour
- initializeForBlockHeader() in CGBlocks.cpp was passing
LangAS::opencl_generic to TargetInfo::getPointer{Width,Align}()
- CodeGenFunction::EmitBlockLiteral() was passing a AST address space to
TargetInfo::getPointerWidth()
- CGOpenMPRuntimeNVPTX::translateParameter() passed a target address space
to Qualifiers::addAddressSpace()
- CGOpenMPRuntimeNVPTX::getParameterAddress() was using
llvm::Type::getPointerTo() with a AST address space
- clang_getAddressSpace() returns either a LangAS or a target address
space. As this is exposed to C I have kept the current behaviour and
added a comment stating that it is probably not correct.
Other than this the patch should not cause any functional changes.
Reviewers: yaxunl, pcc, bader
Reviewed By: yaxunl, bader
Subscribers: jlebar, jholewinski, nhaehnle, Anastasia, cfe-commits
Differential Revision: https://reviews.llvm.org/D38816
llvm-svn: 315871
|
|
|
|
| |
llvm-svn: 315805
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In OpenCL the kernel function and non-kernel function has different calling conventions.
For certain targets they have different argument ABIs. Also kernels have special function
attributes and metadata for runtime to launch them.
The blocks passed to enqueue_kernel is supposed to be executed as kernels. As such,
the block invoke function should be emitted as kernel with proper calling convention and
argument ABI.
This patch emits enqueued block as kernel. If a block is both called directly and passed
to enqueue_kernel, separate functions will be generated.
Differential Revision: https://reviews.llvm.org/D38134
llvm-svn: 315804
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The function sanitizer only checks indirect calls through function
pointers. This excludes all non-static member functions (constructor
calls, calls through thunks, etc. all use a separate code path). Don't
emit function signatures for functions that won't be checked.
Apart from cutting down on code size, this should fix a regression on
Linux caused by r313096. For context, see the mailing list discussion:
r313096 - [ubsan] Function Sanitizer: Don't require writable text segments
Testing: check-clang, check-ubsan
Differential Revision: https://reviews.llvm.org/D38913
llvm-svn: 315786
|
|
|
|
|
|
|
|
|
|
| |
with LValue base info", r315731.
With this change we fail on the clang-x86_64-linux-selfhost-modules builder.
Differential Revision: https://reviews.llvm.org/D38796
llvm-svn: 315739
|
|
|
|
|
|
|
|
| |
base info
Differential Revision: https://reviews.llvm.org/D38796
llvm-svn: 315731
|
|
|
|
|
|
|
|
| |
base info
Differential Revision: https://reviews.llvm.org/D38795
llvm-svn: 315715
|
|
|
|
|
|
|
|
|
|
| |
base info
This patch should not bring in any functional changes.
Differential Revision: https://reviews.llvm.org/D38794
llvm-svn: 315708
|
|
|
|
|
|
|
|
| |
This allows __try inside __finally to work.
Fixes PR34939
llvm-svn: 315707
|
|
|
|
|
|
|
|
|
|
| |
info
This patch should not bring in any functional changes.
Differential Revision: https://reviews.llvm.org/D38793
llvm-svn: 315705
|