Michael Liao [Sat, 19 Oct 2019 00:15:19 +0000 (00:15 +0000)]
[hip][cuda] Fix the extended lambda name mangling issue.
Summary:
- HIP/CUDA host side needs to use device kernel symbol name to match the
device side binaries. Without a consistent naming between host- and
device-side compilations, it's risky that wrong device binaries are
executed. Consistent naming is usually not an issue until unnamed
types are used, especially the lambda. In this patch, the consistent
name mangling is addressed for the extended lambdas, i.e. the lambdas
annotated with `__device__`.
- In [Itanium C++ ABI][1], the mangling of the lambda is generally
unspecified unless, in certain cases, ODR rule is required to ensure
consisent naming cross TUs. The extended lambda is such a case as its
name may be part of a device kernel function, e.g., the extended
lambda is used as a template argument and etc. Thus, we need to force
ODR for extended lambdas as they are referenced in both device- and
host-side TUs. Furthermore, if a extended lambda is nested in other
(extended or not) lambdas, those lambdas are required to follow ODR
naming as well. This patch revises the current lambda mangle numbering
to force ODR from an extended lambda to all its parent lambdas.
- On the other side, the aforementioned ODR naming should not change
those lambdas' original linkages, i.e., we cannot replace the original
`internal` with `linkonce_odr`; otherwise, we may violate ODR in
general. This patch introduces a new field `HasKnownInternalLinkage`
in lambda data to decouple the current linkage calculation based on
mangling number assigned.
Richard Smith [Sat, 19 Oct 2019 00:04:43 +0000 (00:04 +0000)]
[c++20] Add rewriting from comparison operators to <=> / ==.
This adds support for rewriting <, >, <=, and >= to a normal or reversed
call to operator<=>, for rewriting != to a normal or reversed call to
operator==, and for rewriting <=> and == to reversed forms of those same
operators.
Note that this is a breaking change for various C++17 code patterns,
including some in use in LLVM. The most common patterns (where an
operator== becomes ambiguous with a reversed form of itself) are still
accepted under this patch, as an extension (with a warning). I'm hopeful
that we can get the language rules fixed before C++20 ships, and the
extension warning is aimed primarily at providing data to inform that
decision.
Vedant Kumar [Fri, 18 Oct 2019 23:33:40 +0000 (23:33 +0000)]
[profile] Do not cache __llvm_profile_get_filename result
When the %m filename pattern is used, the filename is unique to each
image, so the cached value is wrong.
It struck me that the full filename isn't something that's recomputed
often, so perhaps it doesn't need to be cached at all. David Li pointed
out we can go further and just hide lprofCurFilename. This may regress
workflows that depend on using the set-filename API to change filenames
across all loaded DSOs, but this is expected to be very rare.
Artem Dergachev [Fri, 18 Oct 2019 20:15:39 +0000 (20:15 +0000)]
[analyzer] Fix FieldRegion dumps.
The '->' thing has always been confusing; the actual operation '->'
translates to a pointer dereference together with adding a FieldRegion,
but FieldRegion on its own doesn't imply an additional pointer
dereference.
Artem Dergachev [Fri, 18 Oct 2019 20:15:35 +0000 (20:15 +0000)]
[analyzer] Drop the logic for collapsing the state if it's same as in preds.
One of the first attempts to reduce the size of the exploded graph dumps
was to skip the state dump as long as the state is the same as in all of
the predecessor nodes. With all the new facilities in place (node joining,
diff dumps), this feature doesn't do much, and when it does,
it's more harmful than useful. Let's remove it.
Brian Gesiak [Fri, 18 Oct 2019 16:59:02 +0000 (16:59 +0000)]
[Format] Add format check for throwing negative numbers
Summary:
The code `throw -1;` is currently formatted by clang-format as
`throw - 1;`. This diff adds a fix for this edge case and a test to check
for this in the future.
For context, I am looking into a related bug in the clang-formatting of
coroutine keywords: `co_yield -1;` is also reformatted in this manner
as `co_yield - 1;`. A later diff will add these changes and tests for the
`co_yield` and `co_return` keywords.
[clang-format] fix regression recognizing casts in Obj-C calls
Summary:
r373922 added checks for a few tokens that, following an `)` make it
unlikely that the `)` is the closing paren of a cast expression. The
specific check for `tok::l_square` there introduced a regression for
casts of Obj-C calls, like:
```
(cast)[func arg]
```
From the tests added in r373922, I believe the `tok::l_square` case is added to
capture the case where a non-cast `)` is directly followed by an
attribute specifier, like:
```
int f(int x) [[noreturn]];
```
I've specialized the code to look for such attribute specifier instead
of `tok::l_square` in general. Also, I added a regression test and moved
the test cases added in r373922 to an already existing place documenting
other instances of historically misidentified casts.
Summary:
The sign extension proposal was motivated by a desire to not have
separate sign-extending atomic operations, so it is meant to be
enabled when threads are used.
Artem Dergachev [Thu, 17 Oct 2019 23:10:09 +0000 (23:10 +0000)]
[analyzer] Assign truly stable identifiers to exploded nodes.
ExplodedGraph nodes will now have a numeric identifier stored in them
which will keep track of the order in which the nodes were created
and it will be fully deterministic both accross runs and across machines.
This is extremely useful for debugging as it allows reliably setting
conditional breakpoints by node IDs.
Eli Friedman [Thu, 17 Oct 2019 21:57:28 +0000 (21:57 +0000)]
[ARM] Fix arm_neon.h with -flax-vector-conversions=none, part 3
It's completely impossible to check that I've actually found all the
issues, due to the use of macros in arm_neon.h, but hopefully this time
it'll take more than a few hours for someone to find another issue.
I have no idea why, but apparently there's a rule that some, but not
all, builtins which should take an fp16 vector actually take an int8
vector as an argument. Fix this, and add test coverage.
Alexey Bataev [Thu, 17 Oct 2019 17:12:03 +0000 (17:12 +0000)]
[OPENMP]Improve use of the global tid parameter.
If we can determined, that the global tid parameter can be used in the
function, better to use it rather than calling __kmpc_global_thread_num
function.
James Y Knight [Thu, 17 Oct 2019 15:27:04 +0000 (15:27 +0000)]
[ObjC] Diagnose implicit type coercion from ObjC 'Class' to object
pointer types.
For example, in Objective-C mode, the initialization of 'x' in:
```
@implementation MyType
+ (void)someClassMethod {
MyType *x = self;
}
@end
```
is correctly diagnosed with an incompatible-pointer-types warning, but
in Objective-C++ mode, it is not diagnosed at all -- even though
incompatible pointer conversions generally become an error in C++.
This patch fixes that oversight, allowing implicit conversions
involving Class only to/from unqualified-id, and between qualified and
unqualified Class, where the protocols are compatible.
Note that this does change some behaviors in Objective-C, as well, as
shown by the modified tests.
Of particular note is that assignment from from 'Class<MyProtocol>' to
'id<MyProtocol>' now warns. (Despite appearances, those are not
compatible types. 'Class<MyProtocol>' is not expected to have instance
methods defined by 'MyProtocol', while 'id<MyProtocol>' is.)
James Y Knight [Thu, 17 Oct 2019 15:18:59 +0000 (15:18 +0000)]
[ObjC] Add some additional test cases around pointer conversions.
This is especially important for Objective-C++, which is entirely
missing this testing at the moment.
This annotates with "FIXME" the cases which I change in the next
patch -- I primarily wanted to document the current state of things so
that the effect of the code change is made clear.
PR43145 revealed two places where Clang was attempting to create a
bitcast without considering the address space of class types during
C++ class code generation.
The static analyzer is warning about potential null dereferences, but in these cases we should be able to use castAs<> directly and if not assert will fire for us.
The static analyzer is warning about potential null dereferences, but in these cases we should be able to use castAs<> directly and if not assert will fire for us.
Oliver Stannard [Thu, 17 Oct 2019 09:58:57 +0000 (09:58 +0000)]
Reland: Dead Virtual Function Elimination
Remove dead virtual functions from vtables with
replaceNonMetadataUsesWith, so that CGProfile metadata gets cleaned up
correctly.
Original commit message:
Currently, it is hard for the compiler to remove unused C++ virtual
functions, because they are all referenced from vtables, which are referenced
by constructors. This means that if the constructor is called from any live
code, then we keep every virtual function in the final link, even if there
are no call sites which can use it.
This patch allows unused virtual functions to be removed during LTO (and
regular compilation in limited circumstances) by using type metadata to match
virtual function call sites to the vtable slots they might load from. This
information can then be used in the global dead code elimination pass instead
of the references from vtables to virtual functions, to more accurately
determine which functions are reachable.
To make this transformation safe, I have changed clang's code-generation to
always load virtual function pointers using the llvm.type.checked.load
intrinsic, instead of regular load instructions. I originally tried writing
this using clang's existing code-generation, which uses the llvm.type.test
and llvm.assume intrinsics after doing a normal load. However, it is possible
for optimisations to obscure the relationship between the GEP, load and
llvm.type.test, causing GlobalDCE to fail to find virtual function call
sites.
The existing linkage and visibility types don't accurately describe the scope
in which a virtual call could be made which uses a given vtable. This is
wider than the visibility of the type itself, because a virtual function call
could be made using a more-visible base class. I've added a new
!vcall_visibility metadata type to represent this, described in
TypeMetadata.rst. The internalization pass and libLTO have been updated to
change this metadata when linking is performed.
This doesn't currently work with ThinLTO, because it needs to see every call
to llvm.type.checked.load in the linkage unit. It might be possible to
extend this optimisation to be able to use the ThinLTO summary, as was done
for devirtualization, but until then that combination is rejected in the
clang driver.
To test this, I've written a fuzzer which generates random C++ programs with
complex class inheritance graphs, and virtual functions called through object
and function pointers of different types. The programs are spread across
multiple translation units and DSOs to test the different visibility
restrictions.
I've also tried doing bootstrap builds of LLVM to test this. This isn't
ideal, because only classes in anonymous namespaces can be optimised with
-fvisibility=default, and some parts of LLVM (plugins and bugpoint) do not
work correctly with -fvisibility=hidden. However, there are only 12 test
failures when building with -fvisibility=hidden (and an unmodified compiler),
and this change does not cause any new failures for either value of
-fvisibility.
On the 7 C++ sub-benchmarks of SPEC2006, this gives a geomean code-size
reduction of ~6%, over a baseline compiled with "-O2 -flto
-fvisibility=hidden -fwhole-program-vtables". The best cases are reductions
of ~14% in 450.soplex and 483.xalancbmk, and there are no code size
increases.
I've also run this on a set of 8 mbed-os examples compiled for Armv7M, which
show a geomean size reduction of ~3%, again with no size increases.
I had hoped that this would have no effect on performance, which would allow
it to awlays be enabled (when using -fwhole-program-vtables). However, the
changes in clang to use the llvm.type.checked.load intrinsic are causing ~1%
performance regression in the C++ parts of SPEC2006. It should be possible to
recover some of this perf loss by teaching optimisations about the
llvm.type.checked.load intrinsic, which would make it worth turning this on
by default (though it's still dependent on -fwhole-program-vtables).
Kousik Kumar [Thu, 17 Oct 2019 02:14:44 +0000 (02:14 +0000)]
Include sanitize blacklist and other extra deps as part of scan-deps output
Summary:
Clang's -M mode includes these extra dependencies in its output and clang-scan-deps
should have equivalent behavior, so adding these extradeps to output just like
how its being done for ".d" file generation mode.
Alexey Bataev [Wed, 16 Oct 2019 16:59:01 +0000 (16:59 +0000)]
[OPENMP]Use different addresses for zeroed thread_id/bound_id.
When the parallel region is called directly in the sequential region,
the zeroed tid/bound id are used. But they must point to the different
memory locations as the parameters are marked as noalias.
[libTooling] Fix r374962: add more Transformer forwarding decls.
Summary:
The move to a new, single namespace in r374962 left out some type definitions
from the old namespace and resulted in one naming conflict (`text`). This
revision adds aliases for those definitions and removes one of the `text`
functions from the new namespace.
Simon Tatham [Wed, 16 Oct 2019 13:23:39 +0000 (13:23 +0000)]
[Driver,ARM] Make -mfloat-abi=soft turn off MVE.
Since `-mfloat-abi=soft` is taken to mean turning off all uses of the
FP registers, it should turn off the MVE vector instructions as well
as NEON and scalar FP. But it wasn't doing so.
So the options `-march=armv8.1-m.main+mve.fp+fp.dp -mfloat-abi=soft`
would cause the underlying LLVM to //not// support MVE (because it
knows the real target feature relationships and turned off MVE when
the `fpregs` feature was removed), but the clang layer still thought
it //was// supported, and would misleadingly define the feature macro
`__ARM_FEATURE_MVE`.
The ARM driver code already has a long list of feature names to turn
off when `-mfloat-abi=soft` is selected. The fix is to add the missing
entries `mve` and `mve.fp` to that list.
The static analyzer is warning about potential null dereferences, but in these cases we should be able to use castAs<> directly and if not assert will fire for us.
The static analyzer is warning about potential null dereferences, but in these cases we should be able to use cast<> directly and if not assert will fire for us.
The static analyzer is warning about a potential null dereference, but in these cases we should be able to use castAs<> directly and if not assert will fire for us.
The static analyzer is warning about potential null dereferences, but in these cases we should be able to use castAs<> directly and if not assert will fire for us.
Alexey Bataev [Tue, 15 Oct 2019 19:37:05 +0000 (19:37 +0000)]
[OPENMP]Allow final clause in combined task-based directives.
The condition of the final clause must be captured in the combined
task-based directives, like 'parallel master taskloop' directive.
Sergey Dmitriev [Tue, 15 Oct 2019 18:42:47 +0000 (18:42 +0000)]
[Clang][OpenMP Offload] Move offload registration code to the wrapper
The final list of OpenMP offload targets becomes known only at the link time and since offload registration code depends on the targets list it makes sense to delay offload registration code generation to the link time instead of adding it to the host part of every fat object. This patch moves offload registration code generation from clang to the offload wrapper tool.
This is the last part of the OpenMP linker script elimination patch https://reviews.llvm.org/D64943
Jian Cai [Tue, 15 Oct 2019 18:17:08 +0000 (18:17 +0000)]
[clang] refactor -Wa,-W test cases.
Remove REQUIRES and only keep the clang driver tests, since the
assembler are already tested with -Wa,--no-warn. This way we could run
the test on non-linux platforms and catch breaks on them.
Aaron Ballman [Tue, 15 Oct 2019 17:30:19 +0000 (17:30 +0000)]
Add more information to JSON AST dumping of source locations.
This adds information about the offset within the source file to the given source location as well as information about the include file a location is from. These pieces of information allow for more efficient post-processing of JSON AST dumps.
This reverts commit ec87b003823d63f3342cf648f55a134c1522e612.
The test fails on Windows, see e.g.
http://lab.llvm.org:8011/builders/clang-x64-windows-msvc/builds/11533/steps/stage%201%20check/logs/stdio
Summary:
When files often get touched during builds, the mtime based validation
leads to different problems in implicit modules builds, even when the
content doesn't actually change:
- Modules only: module invalidation due to out of date files. Usually causing rebuild traffic.
- Modules + PCH: build failures because clang cannot rebuild a module if it comes from building a PCH.
- PCH: build failures because clang cannot rebuild a PCH in case one of the input headers has different mtime.
This patch proposes hashing the content of input files (headers and
module maps), which is performed during serialization time. When looking
at input files for validation, clang only computes the hash in case
there's a mtime mismatch.
I've tested a couple of different hash algorithms availble in LLVM in
face of building modules+pch for `#import <Cocoa/Cocoa.h>`:
- `hash_code`: performace diff within the noise, total module cache increased by 0.07%.
- `SHA1`: 5% slowdown. Haven't done real size measurements, but it'd be BLOCK_ID+20 bytes per input file, instead of BLOCK_ID+8 bytes from `hash_code`.
- `MD5`: 3% slowdown. Like above, but BLOCK_ID+16 bytes per input file.
Given the numbers above, the patch uses `hash_code`. The patch also
improves invalidation error msgs to point out which type of problem the
user is facing: "mtime", "size" or "content".
Summary:
This is patch is part of a series to introduce an Alignment type.
See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html
See this patch for the introduction of the type: https://reviews.llvm.org/D64790
Saar Raz [Tue, 15 Oct 2019 11:48:58 +0000 (11:48 +0000)]
[Concepts] Concept Specialization Expressions
Part of C++20 Concepts implementation effort. Added Concept Specialization Expressions that are created when a concept is referenced with arguments, and tests thereof.
Thomas Lively [Tue, 15 Oct 2019 01:11:51 +0000 (01:11 +0000)]
[WebAssembly] Trapping fptoint builtins and intrinsics
Summary:
The WebAssembly backend lowers fptoint instructions to a code sequence
that checks for overflow to avoid traps because fptoint is supposed to
be speculatable. These new builtins and intrinsics give users a way to
depend on the trapping semantics of the underlying instructions and
avoid the extra code generated normally.
Summary:
When files often get touched during builds, the mtime based validation
leads to different problems in implicit modules builds, even when the
content doesn't actually change:
- Modules only: module invalidation due to out of date files. Usually causing rebuild traffic.
- Modules + PCH: build failures because clang cannot rebuild a module if it comes from building a PCH.
- PCH: build failures because clang cannot rebuild a PCH in case one of the input headers has different mtime.
This patch proposes hashing the content of input files (headers and
module maps), which is performed during serialization time. When looking
at input files for validation, clang only computes the hash in case
there's a mtime mismatch.
I've tested a couple of different hash algorithms availble in LLVM in
face of building modules+pch for `#import <Cocoa/Cocoa.h>`:
- `hash_code`: performace diff within the noise, total module cache increased by 0.07%.
- `SHA1`: 5% slowdown. Haven't done real size measurements, but it'd be BLOCK_ID+20 bytes per input file, instead of BLOCK_ID+8 bytes from `hash_code`.
- `MD5`: 3% slowdown. Like above, but BLOCK_ID+16 bytes per input file.
Given the numbers above, the patch uses `hash_code`. The patch also
improves invalidation error msgs to point out which type of problem the
user is facing: "mtime", "size" or "content".
Eric Christopher [Mon, 14 Oct 2019 22:56:07 +0000 (22:56 +0000)]
In the new pass manager use PTO.LoopUnrolling to determine when and how
we will unroll loops. Also comment a few occasions where we need to
know whether or not we're forcing the unwinder or not.
The default before and after this patch is for LoopUnroll to be enabled,
and for it to use a cost model to determine whether to unroll the loop
(`OnlyWhenForced = false`). Before this patch, disabling loop unroll
would not run the LoopUnroll pass. After this patch, the LoopUnroll pass
is being run, but it restricts unrolling to only the loops marked by a
pragma (`OnlyWhenForced = true`).
In addition, this patch disables the UnrollAndJam pass when disabling unrolling.
Testcase is in clang because it's controlling how the loop optimizer
is being set up and there's no other way to trigger the behavior.
Eli Friedman [Mon, 14 Oct 2019 22:44:42 +0000 (22:44 +0000)]
[test] Fix test failure
The version mismatch symbol is version 9 on 32 bit android. Since
this test isn't actually testing any android specific functionality,
we force the target triple to x86_64-unknown-unknown in order to have
a consistent version number. It seems the test was already trying to
do this, just not doing it right
Jian Cai [Mon, 14 Oct 2019 22:28:03 +0000 (22:28 +0000)]
Add support to -Wa,-W in clang
Summary:
Currently clang does not support -Wa,-W, which suppresses warning
messages in GNU assembler. Add this option for gcc compatibility.
https://bugs.llvm.org/show_bug.cgi?id=43651. Reland with differential
information.
Richard Smith [Mon, 14 Oct 2019 21:53:03 +0000 (21:53 +0000)]
PR43080: Do not build context-sensitive expressions during name classification.
Summary:
We don't know what context to use until the classification result is
consumed by the parser, which could happen in a different semantic
context. So don't build the expression that results from name
classification until we get to that point and can handle it properly.
This covers everything except C++ implicit class member access, which
is a little awkward to handle properly in the face of the protected
member access check. But it at least fixes all the currently-filed
instances of PR43080.
Jian Cai [Mon, 14 Oct 2019 21:21:39 +0000 (21:21 +0000)]
Add support to -Wa,-W in clang
Currently clang does not support -Wa,-W, which suppresses warning
messages in GNU assembler. Add this option for gcc compatibility.
https://bugs.llvm.org/show_bug.cgi?id=43651
Puyan Lotfi [Mon, 14 Oct 2019 18:03:03 +0000 (18:03 +0000)]
[clang][IFS] Escape mangled names so MS ABI doesn't break YAML parsing.
Microsoft's ABI mangles names differently than Itanium and this breaks the LLVM
yaml parser unless the name is escaped in quotes. Quotes are being added to the
mangled names of the IFS file generation so that llvm-ifs doesn't break when
Windows triples are passed to the driver.
Alexey Bataev [Mon, 14 Oct 2019 17:17:41 +0000 (17:17 +0000)]
[OPENMP50]Add support for 'parallel master taskloop' construct.
Added parsing/sema/codegen support for 'parallel master taskloop'
constructs. Some of the clauses, like 'grainsize', 'num_tasks', 'final'
and 'priority' are not supported in full, only constant expressions can
be used currently in these clauses.
Alexey Bataev [Mon, 14 Oct 2019 16:44:01 +0000 (16:44 +0000)]
[OPENMP]Fix codegen for private variably length vars in combined
constructs.
If OpenMP construct includes several capturing regions and the variable
is declared as private, the length of the inner variable length array is
not captured in outer captured regions, only in the innermost region.
Patch fixes this bug.
Diogo N. Sampaio [Mon, 14 Oct 2019 16:29:26 +0000 (16:29 +0000)]
[ARM] Preserve fpu behaviour for '-crypto'
Summary:
This patch restores the behaviour that -fpu overwrites the
architecture obtained from -march or -mcpu flags, not enforcing to
disable 'crypto' if march=armv7 and mfpu=neon-fp-armv8.
However, it does warn that 'crypto' is ignored when passing
mfpu=crypto-neon-fp-armv8.
projects / clang / log