In the PR, Clang ended up in a situation where it tried to mangle the
__float128 type, which isn't supported when targetingt MSVC, because
Clang instantiated a variable template with that type when searching for
a conversion to use in an arithmetic expression.
Differential revision: https://reviews.llvm.org/D39579
llvm-svn: 318309
Summary:
Constant samplers are handled as static variables and clang's code generation
library, which leads to llvm::unreachable. We bypass emitting sampler variable
as static since it's translated to a function call later.
Reviewers: yaxunl, Anastasia
Reviewed By: yaxunl, Anastasia
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D34342
llvm-svn: 318290
Lifting from Bob Wilson's notes: The hash value that we compute and
store in PGO profile data to detect out-of-date profiles does not
include enough information. This means that many significant changes to
the source will not cause compiler warnings about the profile being out
of date, and worse, we may continue to use the outdated profile data to
make bad optimization decisions. There is some tension here because
some source changes won't affect PGO and we don't want to invalidate the
profile unnecessarily.
This patch adds a new hashing scheme which is more sensitive to loop
nesting, conditions, and out-of-order control flow. Here are examples
which show snippets which get the same hash under the current scheme,
and different hashes under the new scheme:
Loop Nesting Example
--------------------
// Snippet 1
while (foo()) {
while (bar()) {}
}
// Snippet 2
while (foo()) {}
while (bar()) {}
Condition Example
-----------------
// Snippet 1
if (foo())
bar();
baz();
// Snippet 2
if (foo())
bar();
else
baz();
Out-of-order Control Flow Example
---------------------------------
// Snippet 1
while (foo()) {
if (bar()) {}
baz();
}
// Snippet 2
while (foo()) {
if (bar())
continue;
baz();
}
In each of these cases, it's useful to differentiate between the
snippets because swapping their profiles gives bad optimization hints.
The new hashing scheme considers some logical operators in an effort to
detect more changes in conditions. This isn't a perfect scheme. E.g, it
does not produce the same hash for these equivalent snippets:
// Snippet 1
bool c = !a || b;
if (d && e) {}
// Snippet 2
bool f = d && e;
bool c = !a || b;
if (f) {}
This would require an expensive data flow analysis. Short of that, the
new hashing scheme looks reasonably complete, based on a scan over the
statements we place counters on.
Profiles which use the old version of the PGO hash remain valid and can
be used without issue (there are tests in tree which check this).
rdar://17068282
Differential Revision: https://reviews.llvm.org/D39446
llvm-svn: 318229
On e.g. PPC the return value and argument were marked 'signext'. This
makes the test expectations a bit more flexible.
Follow-up to r318199.
llvm-svn: 318214
This updates -mcount to use the new attribute names (LLVM r318195), and
switches over -finstrument-functions to also use these attributes rather
than inserting instrumentation in the frontend.
It also adds a new flag, -finstrument-functions-after-inlining, which
makes the cygprofile instrumentation get inserted after inlining rather
than before.
Differential Revision: https://reviews.llvm.org/D39331
llvm-svn: 318199
Not much interesting here. Mostly wiring things together.
One thing worth noting is that the approach is substantially different
from the old PM. Here, the -O0 case works fundamentally differently in
that we just directly build the pipeline without any callbacks or other
cruft. In some ways, this is nice and clean. However, I don't like that
it causes the sanitizers to be enabled with different changes at
different times. =/ Suggestions for a better way to do this are welcome.
Differential Revision: https://reviews.llvm.org/D39085
llvm-svn: 318131
This reverts the aforementioned patch and 2 subsequent follow-ups,
as some buildbots are still failing 2 tests because of it.
Investigation is ongoing into the cause of the failures.
llvm-svn: 318112
cbrt() is always constant because it can't overflow or underflow. Therefore, it can't set errno.
fma() is not always constant because it can overflow or underflow. Therefore, it can set errno.
But we know that it never sets errno on GNU / MSVC, so make it constant in those environments.
Differential Revision: https://reviews.llvm.org/D39641
llvm-svn: 318093
The ObjCGenerics checker warns on a cast when there is no subtyping relationship
between the tracked type of the value and the destination type of the cast. It
does this even if the cast was explicitly written. This means the user can't
write an explicit cast to silence the diagnostic.
This commit treats explicit casts involving generic types as an indication from
the programmer that the Objective-C type system is not rich enough to express
the needed invariant. On explicit casts, the checker now removes any existing
information inferred about the type arguments. Further, it no longer assumes
the casted-to specialized type because the invariant the programmer specifies
in the cast may only hold at a particular program point and not later ones. This
prevents a suppressing cast from requiring a cascade of casts down the
line.
rdar://problem/33603303
Differential Revision: https://reviews.llvm.org/D39711
llvm-svn: 318054
Recommit of r317951 and r317951 along with what I believe should fix
the remaining buildbot failures - the target triple should be specified
for both the ThinLTO pre-thinlink compile and backend (post-thinlink)
compile to ensure it is consistent.
Original description:
The LTO Config field wasn't being set when invoking a ThinLTO backend
via clang (i.e. for distributed builds).
llvm-svn: 318042
Change Header files of the intrinsics for lowering test and testn intrinsics to IR code.
Removed test and testn builtins from clang
Differential Revision: https://reviews.llvm.org/D38737
llvm-svn: 318035
This patch, together with a matching llvm patch (https://reviews.llvm.org/D38671), implements the lowering of X86 shuffle i/f intrinsics to IR.
Differential Revision: https://reviews.llvm.org/D38672
Change-Id: I9b3c2f2b34323bd9ccb21d0c1832f848b88ec047
llvm-svn: 318025
Summary:
We don't want to store cleanup dest slot saved into the coroutine frame (as some of the cleanup code may
access them after coroutine frame destroyed).
This is an alternative to https://reviews.llvm.org/D37093
It is possible to do this for all functions, but, cursory check showed that in -O0, we get slightly longer function (by 1-3 instructions), thus, we are only limiting cleanup.dest.slot elimination to coroutines.
Reviewers: rjmccall, hfinkel, eric_niebler
Reviewed By: eric_niebler
Subscribers: EricWF, cfe-commits
Differential Revision: https://reviews.llvm.org/D39768
llvm-svn: 317981
From http://reviews.llvm.org/D4368 these cases were thought to not be reachable
and the checks removed before the rest of the code was committed in r216649.
However, these cases are reachable and the checks are added back.
llvm-svn: 317957
Summary:
The LTO Config field wasn't being set when invoking a ThinLTO backend
via clang (i.e. for distributed builds).
Reviewers: danielcdh
Subscribers: mehdi_amini, inglorion, eraman, cfe-commits
Differential Revision: https://reviews.llvm.org/D39923
llvm-svn: 317951
Previously, debuginfo-tests was expected to be checked out into
clang/test and then the tests would automatically run as part of
check-clang. This is not a standard workflow for handling
external projects, and it brings with it some serious drawbacks
such as the inability to depend on things other than clang, which
we will need going forward.
The goal of this patch is to migrate towards a more standard
workflow. To ease the transition for build bot maintainers,
this patch tries not to break the existing workflow, but instead
simply deprecate it to give maintainers a chance to update
the build infrastructure.
Differential Revision: https://reviews.llvm.org/D39605
llvm-svn: 317925
Summary:
[OpenMP] diagnose assign to firstprivate const
Clang does not diagnose assignments to const variables declared
firstprivate. Furthermore, codegen is broken such that, at run time,
such assignments simply have no effect. For example, the following
prints 0 not 1:
int main() {
const int i = 0;
#pragma omp parallel firstprivate(i)
{ i=1; printf("%d\n", i); }
return 0;
}
This commit makes these assignments a compile error, which is
consistent with other OpenMP compilers I've tried (pgcc 17.4-0, gcc
6.3.0).
Reviewers: ABataev
Reviewed By: ABataev
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D39859
llvm-svn: 317891
The backend should be able to combine the negates to create fmsub, fnmadd, and fnmsub. faddsub converting to fsubadd still needs work I think, but should be very doable.
This matches what we already do for the masked builtins.
This only covers the packed builtins. Scalar builtins will be done after FMA4 is fixed.
llvm-svn: 317873
Summary:
This is basically reverting r261774 with a tweak for clang-cl. UNIX
standard states:
When c99 encounters a compilation error that causes an object file not
to be created, it shall write a diagnostic to standard error and
continue to compile other source code operands, but it shall not perform
the link phase and it shall return a non-zero exit status
The same goes for c89 or cc. And they are all alias or shims pointing to
clang on Darwin.
The original commit was intended for CUDA so the error message doesn't
get emit twice for both host and device. It seems that the clang driver
has been changed to model the CUDA dependency differently. Now the
driver behaves the same without this commit.
rdar://problem/32223263
Reviewers: thakis, dexonsmith, tra
Reviewed By: tra
Subscribers: jlebar, cfe-commits
Differential Revision: https://reviews.llvm.org/D39502
llvm-svn: 317860
This is the issue breaking the postgresql bot, purely by chance exposed
through taint checker, somehow appearing after
https://reviews.llvm.org/D38358 got committed.
The backstory is that the taint checker requests SVal for the value of
the pointer, and analyzer has a "fast path" in the getter to return a
constant when we know that the value is constant.
Unfortunately, the getter requires a cast to get signedness correctly,
and for the pointer `void *` the cast crashes.
This is more of a band-aid patch, as I am not sure what could be done
here "correctly", but it should be applied in any case to avoid the
crash.
Differential Revision: https://reviews.llvm.org/D39862
llvm-svn: 317839
The 'decl' role is more canonical than the 'ref'. This helps us establish the
'specialization-of' relation just by looking at decls or defs.
rdar://31884960
llvm-svn: 317832
Patches the solver to assume that bitwise OR of an unsigned value with a
constant always produces a value larger-or-equal than the constant, and
bitwise AND with a constant always produces a value less-or-equal than
the constant.
This patch is especially useful in the context of using bitwise
arithmetic for error code encoding: the analyzer would be able to state
that the error code produced using a bitwise OR is non-zero.
Differential Revision: https://reviews.llvm.org/D39707
llvm-svn: 317820
Summary:
This is an alternative to JSONCompilationDatabase for simple projects that
don't use a build system such as CMake.
(You can also drop one in ~, to make your tools use e.g. C++11 by default)
There's no facility for varying flags per-source-file or per-machine.
Possibly this could be accommodated backwards-compatibly using cpp, but even if
not the simplicity seems worthwhile for the cases that are addressed.
Tested with clangd, works great! (requires clangd restart)
Reviewers: klimek
Subscribers: ilya-biryukov, cfe-commits
Differential Revision: https://reviews.llvm.org/D39799
llvm-svn: 317777
There are some limitations with emitting regions in macro expansions
because we don't gather file IDs within the expansions. Fix the check
that prevents us from emitting deferred regions in expansions to make an
exception for headers, which is something we can handle.
rdar://35373009
llvm-svn: 317760
The area immediately after a terminated region in the function top-level
should have the same count as the label it precedes.
This solves another problem with wrapped segments. Consider:
1| a:
2| return 0;
3| b:
4| return 1;
Without a gap area starting after the first return, the wrapped segment
from line 2 would make it look like line 3 is executed, when it's not.
rdar://35373009
llvm-svn: 317759
The area immediately after the closing right-paren of an if condition
should have a count equal to the 'then' block's count. Use a gap region
to set this count, so that region highlighting for the 'then' block
remains precise.
This solves a problem we have with wrapped segments. Consider:
1| if (false)
2| foo();
Without a gap area starting after the condition, the wrapped segment
from line 1 would make it look like line 2 is executed, when it's not.
rdar://35373009
llvm-svn: 317758
Block literals can have a type with attributes in its signature, e.g.
ns_returns_retained. The code that inspected the type loc of the block when
declaring its parameters didn't account for this fact, and only looked through
paren type loc. This commit ensures that getAsAdjusted is used instead of
IgnoreParens to find the block's FunctionProtoTypeLoc. This ensures that
block parameters are declared correctly in the block and avoids the
'undeclared identifier' error.
rdar://35416160
llvm-svn: 317736
Objective-C NSString has a class method stringWithUTF8String that creates a new
NSString from a C string. Objective-C box expression @(...) can be used to
create an NSString instead of invoking the stringWithUTF8String method directly
(The compiler lowers it down to the invocation though). This commit ensures that
the type of @(string-value) gets the same nullability attributes as the return
type of stringWithUTF8String to ensure that the diagnostics are consistent
between the two.
rdar://33847186
Differential Revision: https://reviews.llvm.org/D39762
llvm-svn: 317727
Alex Lorenz