[Windows SEH]: HARDWARE EXCEPTION HANDLING (MSVC -EHa) - Part 1

This patch is the Part-1 (FE Clang) implementation of HW Exception handling.

This new feature adds the support of Hardware Exception

[Windows SEH]: HARDWARE EXCEPTION HANDLING (MSVC -EHa) - Part 1

This patch is the Part-1 (FE Clang) implementation of HW Exception handling.

This new feature adds the support of Hardware Exception for Microsoft Windows
SEH (Structured Exception Handling).
This is the first step of this project; only X86_64 target is enabled in this patch.

Compiler options:
For clang-cl.exe, the option is -EHa, the same as MSVC.
For clang.exe, the extra option is -fasync-exceptions,
plus -triple x86_64-windows -fexceptions and -fcxx-exceptions as usual.

NOTE:: Without the -EHa or -fasync-exceptions, this patch is a NO-DIFF change.

The rules for C code:
For C-code, one way (MSVC approach) to achieve SEH -EHa semantic is to follow
three rules:
* First, no exception can move in or out of _try region., i.e., no "potential
faulty instruction can be moved across _try boundary.
* Second, the order of exceptions for instructions 'directly' under a _try
must be preserved (not applied to those in callees).
* Finally, global states (local/global/heap variables) that can be read
outside of _try region must be updated in memory (not just in register)
before the subsequent exception occurs.

The impact to C++ code:
Although SEH is a feature for C code, -EHa does have a profound effect on C++
side. When a C++ function (in the same compilation unit with option -EHa ) is
called by a SEH C function, a hardware exception occurs in C++ code can also
be handled properly by an upstream SEH _try-handler or a C++ catch(...).
As such, when that happens in the middle of an object's life scope, the dtor
must be invoked the same way as C++ Synchronous Exception during unwinding
process.

Design:
A natural way to achieve the rules above in LLVM today is to allow an EH edge
added on memory/computation instruction (previous iload/istore idea) so that
exception path is modeled in Flow graph preciously. However, tracking every
single memory instruction and potential faulty instruction can create many
Invokes, complicate flow graph and possibly result in negative performance
impact for downstream optimization and code generation. Making all
optimizations be aware of the new semantic is also substantial.

This design does not intend to model exception path at instruction level.
Instead, the proposed design tracks and reports EH state at BLOCK-level to
reduce the complexity of flow graph and minimize the performance-impact on CPP
code under -EHa option.

One key element of this design is the ability to compute State number at
block-level. Our algorithm is based on the following rationales:

A _try scope is always a SEME (Single Entry Multiple Exits) region as jumping
into a _try is not allowed. The single entry must start with a seh_try_begin()
invoke with a correct State number that is the initial state of the SEME.
Through control-flow, state number is propagated into all blocks. Side exits
marked by seh_try_end() will unwind to parent state based on existing
SEHUnwindMap[].
Note side exits can ONLY jump into parent scopes (lower state number).
Thus, when a block succeeds various states from its predecessors, the lowest
State triumphs others. If some exits flow to unreachable, propagation on those
paths terminate, not affecting remaining blocks.
For CPP code, object lifetime region is usually a SEME as SEH _try.
However there is one rare exception: jumping into a lifetime that has Dtor but
has no Ctor is warned, but allowed:

Warning: jump bypasses variable with a non-trivial destructor

In that case, the region is actually a MEME (multiple entry multiple exits).
Our solution is to inject a eha_scope_begin() invoke in the side entry block to
ensure a correct State.

Implementation:
Part-1: Clang implementation described below.

Two intrinsic are created to track CPP object scopes; eha_scope_begin() and eha_scope_end().
_scope_begin() is immediately added after ctor() is called and EHStack is pushed.
So it must be an invoke, not a call. With that it's also guaranteed an
EH-cleanup-pad is created regardless whether there exists a call in this scope.
_scope_end is added before dtor(). These two intrinsics make the computation of
Block-State possible in downstream code gen pass, even in the presence of
ctor/dtor inlining.

Two intrinsic, seh_try_begin() and seh_try_end(), are added for C-code to mark
_try boundary and to prevent from exceptions being moved across _try boundary.
All memory instructions inside a _try are considered as 'volatile' to assure
2nd and 3rd rules for C-code above. This is a little sub-optimized. But it's
acceptable as the amount of code directly under _try is very small.

Part-2 (will be in Part-2 patch): LLVM implementation described below.

For both C++ & C-code, the state of each block is computed at the same place in
BE (WinEHPreparing pass) where all other EH tables/maps are calculated.
In addition to _scope_begin & _scope_end, the computation of block state also
rely on the existing State tracking code (UnwindMap and InvokeStateMap).

For both C++ & C-code, the state of each block with potential trap instruction
is marked and reported in DAG Instruction Selection pass, the same place where
the state for -EHsc (synchronous exceptions) is done.
If the first instruction in a reported block scope can trap, a Nop is injected
before this instruction. This nop is needed to accommodate LLVM Windows EH
implementation, in which the address in IPToState table is offset by +1.
(note the purpose of that is to ensure the return address of a call is in the
same scope as the call address.

The handler for catch(...) for -EHa must handle HW exception. So it is
'adjective' flag is reset (it cannot be IsStdDotDot (0x40) that only catches
C++ exceptions).
Suppress push/popTerminate() scope (from noexcept/noTHrow) so that HW
exceptions can be passed through.

Original llvm-dev [RFC] discussions can be found in these two threads below:
https://lists.llvm.org/pipermail/llvm-dev/2020-March/140541.html
https://lists.llvm.org/pipermail/llvm-dev/2020-April/141338.html

Differential Revision: https://reviews.llvm.org/D80344/new/

show more ...

Fix null ptr crash dumping TemplateTemplateParmDecl

The following program winds up with
D->getDefaultArgStorage().getInheritedFrom() == nullptr
during dumping the TemplateTemplateParmDecl correspond

Fix null ptr crash dumping TemplateTemplateParmDecl

The following program winds up with
D->getDefaultArgStorage().getInheritedFrom() == nullptr
during dumping the TemplateTemplateParmDecl corresponding to the
template parameter of i.

template <typename>
struct R;
template <template <typename> class = R>
void i();

This patch fixes the null pointer dereference.

show more ...

Revert "[NFC, Refactor] Modernize StorageClass from Specifiers.h to a scoped enum (II)"

This reverts commit efc82c4ad2bcb256a4f4c20238d08cd3afba4d2d.

[NFC, Refactor] Modernize StorageClass from Specifiers.h to a scoped enum (II)

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D93765

[clang][NFC] Use SmallString instead of SmallVector<char

Simplifies code in some places and is more explicit about what is being used.
No additional includes were added here so no impact on compile

[clang][NFC] Use SmallString instead of SmallVector<char

Simplifies code in some places and is more explicit about what is being used.
No additional includes were added here so no impact on compile time.

show more ...

[Sema][AArch64] Support arm_sve_vector_bits attribute

This patch implements the semantics for the 'arm_sve_vector_bits' type
attribute, defined by the Arm C Language Extensions (ACLE) for SVE [1].
T

[Sema][AArch64] Support arm_sve_vector_bits attribute

This patch implements the semantics for the 'arm_sve_vector_bits' type
attribute, defined by the Arm C Language Extensions (ACLE) for SVE [1].
The purpose of this attribute is to define vector-length-specific (VLS)
versions of existing vector-length-agnostic (VLA) types.

The semantics were already implemented by D83551, although the
implementation approach has since changed to represent VLSTs as
VectorType in the AST and fixed-length vectors in the IR everywhere
except in function args/returns. This is described in the prototype
patch D85128 demonstrating the new approach.

The semantic changes added in D83551 are changed since the
AttributedType is replaced by VectorType in the AST. Minimal changes
were necessary in the previous patch as the canonical type for both VLA
and VLS was the same (i.e. sizeless), except in constructs such as
globals and structs where sizeless types are unsupported. This patch
reverts the changes that permitted VLS types that were represented as
sizeless types in such circumstances, and adds support for implicit
casting between VLA <-> VLS types as described in section 3.7.3.2 of the
ACLE.

Since the SVE builtin types for bool and uint8 are both represented as
BuiltinType::UChar in VLSTs, two new vector kinds are implemented to
distinguish predicate and data vectors.

[1] https://developer.arm.com/documentation/100987/latest

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D85736

show more ...

[clang] Rework how and when APValues are dumped

Currently APValues are dumped as a single string. This becomes quickly
completely unreadable since APValue is a tree-like structure. Even a simple
exa

[clang] Rework how and when APValues are dumped

Currently APValues are dumped as a single string. This becomes quickly
completely unreadable since APValue is a tree-like structure. Even a simple
example is not pretty:

struct S { int arr[4]; float f; };
constexpr S s = { .arr = {1,2}, .f = 3.1415f };
// Struct fields: Array: Int: 1, Int: 2, 2 x Int: 0, Float: 3.141500e+00

With this patch this becomes:

-Struct
|-field: Array size=4
| |-elements: Int 1, Int 2
| `-filler: 2 x Int 0
`-field: Float 3.141500e+00

Additionally APValues are currently only dumped as part of visiting a
ConstantExpr. This patch also dump the value of the initializer of constexpr
variable declarations:

constexpr int foo(int a, int b) { return a + b - 42; }
constexpr int a = 1, b = 2;
constexpr int c = foo(a, b) > 0 ? foo(a, b) : foo(b, a);
// VarDecl 0x62100008aec8 <col:3, col:57> col:17 c 'const int' constexpr cinit
// |-value: Int -39
// `-ConditionalOperator 0x62100008b4d0 <col:21, col:57> 'int'
// <snip>

Do the above by moving the dump functions to TextNodeDumper which already has
the machinery to display trees. The cases APValue::LValue, APValue::MemberPointer
and APValue::AddrLabelDiff are left as they were before (unimplemented).

We try to display multiple elements on the same line if they are considered to
be "simple". This is to avoid wasting large amounts of vertical space in an
example like:

constexpr int arr[8] = {0,1,2,3,4,5,6,7};
// VarDecl 0x62100008bb78 <col:3, col:42> col:17 arr 'int const[8]' constexpr cinit
// |-value: Array size=8
// | |-elements: Int 0, Int 1, Int 2, Int 3
// | `-elements: Int 4, Int 5, Int 6, Int 7

Differential Revision: https://reviews.llvm.org/D83183

Reviewed By: aaron.ballman

show more ...

[AST] Dump containsErrors bit for the Type.

Reviewers: sammccall

Subscribers: cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D81912

[clang] Rename Decl::isHidden() to isUnconditionallyVisible().

Also invert the sense of the return value.

As pointed out by the FIXME that this change resolves, isHidden() wasn't
a very accurate na

[clang] Rename Decl::isHidden() to isUnconditionallyVisible().

Also invert the sense of the return value.

As pointed out by the FIXME that this change resolves, isHidden() wasn't
a very accurate name for this function.

I haven't yet changed any of the strings that are output in
ASTDumper.cpp / JSONNodeDumper.cpp / TextNodeDumper.cpp in response to
whether isHidden() is set because

a) I'm not sure whether it's actually desired to change these strings
(would appreciate feedback on this), and

b) In any case, I'd like to get this pure rename out of the way first,
without any changes to tests. Changing the strings that are output in
the various ...Dumper.cpp files will require changes to quite a few
tests, and I'd like to make those in a separate change.

Differential Revision: https://reviews.llvm.org/D81392

Reviewed By: rsmith

show more ...

[clang][NFC] Generate the {Type,ArrayType,UnaryExprOrType,Expression}Traits...

...enumerations from TokenKinds.def and use the new macros from TokenKinds.def
to remove the hard-coded lists of traits

[clang][NFC] Generate the {Type,ArrayType,UnaryExprOrType,Expression}Traits...

...enumerations from TokenKinds.def and use the new macros from TokenKinds.def
to remove the hard-coded lists of traits.

All the information needed to generate these enumerations is already present
in TokenKinds.def. The motivation here is to be able to dump the trait spelling
without hard-coding the list in yet another place.

Note that this change the order of the enumerators in the enumerations (except
that in the TypeTrait enumeration all unary type traits are before all binary
type traits, and all binary type traits are before all n-ary type traits).

Apart from the aforementioned ordering which is relied upon, after this patch
no code in clang or in the various clang tools depend on the specific ordering
of the enumerators.

No functional changes intended.

Differential Revision: https://reviews.llvm.org/D81455

Reviewed By: aaron.ballman

show more ...

PR46209: properly determine whether a copy assignment operator is
trivial.

We previously took a shortcut by assuming that if a subobject had a
trivial copy assignment operator (with a few side-condi

PR46209: properly determine whether a copy assignment operator is
trivial.

We previously took a shortcut by assuming that if a subobject had a
trivial copy assignment operator (with a few side-conditions), we would
always invoke it, and could avoid going through overload resolution.
That turns out to not be correct in the presenve of ref-qualifiers (and
also won't be the case for copy-assignments with requires-clauses
either). Use the same logic for lazy declaration of copy-assignments
that we use for all other special member functions.

Previously committed as c57f8a3a20540fcf9fbf98c0a73f381ec32fce2a. This
now also includes an extension of LLDB's workaround for handling special
members without the help of Sema to cover copy assignments.

show more ...

Revert "PR46209: properly determine whether a copy assignment operator is"

This reverts commit c57f8a3a20540fcf9fbf98c0a73f381ec32fce2a.

PR46209: properly determine whether a copy assignment operator is
trivial.

We previously took a shortcut by assuming that if a subobject had a
trivial copy assignment operator (with a few side-condi

PR46209: properly determine whether a copy assignment operator is
trivial.

We previously took a shortcut by assuming that if a subobject had a
trivial copy assignment operator (with a few side-conditions), we would
always invoke it, and could avoid going through overload resolution.
That turns out to not be correct in the presenve of ref-qualifiers (and
also won't be the case for copy-assignments with requires-clauses
either). Use the same logic for lazy declaration of copy-assignments
that we use for all other special member functions.

show more ...

[clangd] Add access specifier information to hover contents

Summary:
For https://github.com/clangd/clangd/issues/382

This commit adds access specifier information to the hover
contents. For example

[clangd] Add access specifier information to hover contents

Summary:
For https://github.com/clangd/clangd/issues/382

This commit adds access specifier information to the hover
contents. For example, the hover information of a class field or
member function will now indicate if the field or member is private,
public, or protected. This can be particularly useful when a developer
is in the implementation file and wants to know if a particular member
definition is public or private.

Reviewers: kadircet

Reviewed By: kadircet

Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, kadircet, usaxena95, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D80472

show more ...

[NFC] Refactoring PropertyAttributeKind for ObjCPropertyDecl and ObjCDeclSpec.

This is a code clean up of the PropertyAttributeKind and
ObjCPropertyAttributeKind enums in ObjCPropertyDecl and ObjCDe

[NFC] Refactoring PropertyAttributeKind for ObjCPropertyDecl and ObjCDeclSpec.

This is a code clean up of the PropertyAttributeKind and
ObjCPropertyAttributeKind enums in ObjCPropertyDecl and ObjCDeclSpec that are
exactly identical. This non-functional change consolidates these enums
into one. The changes are to many files across clang (and comments in LLVM) so
that everything refers to the new consolidated enum in DeclObjCCommon.h.

2nd Landing Attempt...

Differential Revision: https://reviews.llvm.org/D77233

show more ...

Revert "[NFC] Refactoring PropertyAttributeKind for ObjCPropertyDecl and ObjCDeclSpec."

This reverts commit 2aa044ed088ae41461ad7029c055014df6c60976.

Reverting due to bot failure in lldb.

[NFC] Refactoring PropertyAttributeKind for ObjCPropertyDecl and ObjCDeclSpec.

This is a code clean up of the PropertyAttributeKind and
ObjCPropertyAttributeKind enums in ObjCPropertyDecl and ObjCDe

[NFC] Refactoring PropertyAttributeKind for ObjCPropertyDecl and ObjCDeclSpec.

This is a code clean up of the PropertyAttributeKind and
ObjCPropertyAttributeKind enums in ObjCPropertyDecl and ObjCDeclSpec that are
exactly identical. This non-functional change consolidates these enums
into one. The changes are to many files across clang (and comments in LLVM) so
that everything refers to the new consolidated enum in DeclObjCCommon.h.

Differential Revision: https://reviews.llvm.org/D77233

show more ...

[CodeGen] Emit destructor calls to destruct compound literals

Fix a bug in IRGen where it wasn't destructing compound literals in C
that are ObjC pointer arrays or non-trivial structs. Also diagnose

[CodeGen] Emit destructor calls to destruct compound literals

Fix a bug in IRGen where it wasn't destructing compound literals in C
that are ObjC pointer arrays or non-trivial structs. Also diagnose jumps
that enter or exit the lifetime of the compound literals.

rdar://problem/51867864

Differential Revision: https://reviews.llvm.org/D64464

show more ...

Avoid SourceManager.h include in RawCommentList.h, add missing incs

SourceManager.h includes FileManager.h, which is expensive due to
dependencies on LLVM FS headers.

Remove dead BeforeThanCompare

Avoid SourceManager.h include in RawCommentList.h, add missing incs

SourceManager.h includes FileManager.h, which is expensive due to
dependencies on LLVM FS headers.

Remove dead BeforeThanCompare specialization.

Sink ASTContext::addComment to cpp file.

This reduces the time to compile a file that does nothing but include
ASTContext.h from ~3.4s to ~2.8s for me.

Saves these includes:
219 - ../clang/include/clang/Basic/SourceManager.h
204 - ../clang/include/clang/Basic/FileSystemOptions.h
204 - ../clang/include/clang/Basic/FileManager.h
165 - ../llvm/include/llvm/Support/VirtualFileSystem.h
164 - ../llvm/include/llvm/Support/SourceMgr.h
164 - ../llvm/include/llvm/Support/SMLoc.h
161 - ../llvm/include/llvm/Support/Path.h
141 - ../llvm/include/llvm/ADT/BitVector.h
128 - ../llvm/include/llvm/Support/MemoryBuffer.h
124 - ../llvm/include/llvm/Support/FileSystem.h
124 - ../llvm/include/llvm/Support/Chrono.h
124 - .../MSVCSTL/include/stack
122 - ../llvm/include/llvm-c/Types.h
122 - ../llvm/include/llvm/Support/NativeFormatting.h
122 - ../llvm/include/llvm/Support/FormatProviders.h
122 - ../llvm/include/llvm/Support/CBindingWrapping.h
122 - .../MSVCSTL/include/xtimec.h
122 - .../MSVCSTL/include/ratio
122 - .../MSVCSTL/include/chrono
121 - ../llvm/include/llvm/Support/FormatVariadicDetails.h
118 - ../llvm/include/llvm/Support/MD5.h
109 - .../MSVCSTL/include/deque
105 - ../llvm/include/llvm/Support/Host.h
105 - ../llvm/include/llvm/Support/Endian.h

Reviewed By: aaron.ballman, hans

Differential Revision: https://reviews.llvm.org/D75279

show more ...

[NFC] Remove trailing space

sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h,td}

[Wdocumentation] Implement \anchor

Differential revision: https://reviews.llvm.org/D69223

Differentiate between the presumed and actual file when dumping the AST to JSON

Currently, when dumping the AST to JSON, the presumed file is what is included
when dumping a source location. This pa

Differentiate between the presumed and actual file when dumping the AST to JSON

Currently, when dumping the AST to JSON, the presumed file is what is included
when dumping a source location. This patch changes the behavior to instead dump
the actual file, and only dump a presumed file name when it differs from the
actual file.

This also corrects an issue with the test script generator that would prevent
it from working on Windows due to file permissions issues.

show more ...

[DeclCXX] Remove unknown external linkage specifications

Partial revert of r372681 "Support for DWARF-5 C++ language tags".

The change introduced new external linkage languages ("C++11" and
"C++14"

[DeclCXX] Remove unknown external linkage specifications

Partial revert of r372681 "Support for DWARF-5 C++ language tags".

The change introduced new external linkage languages ("C++11" and
"C++14") which not supported in C++.

It also changed the definition of the existing enum to use the DWARF
constants. The problem is that "LinkageSpecDeclBits.Language" (the field
that reserves this enum) is actually defined as 3 bits length
(bitfield), which cannot contain the new DWARF constants. Defining the
enum as integer literals is more appropriate for maintaining valid
values.

Differential Revision: https://reviews.llvm.org/D69935

show more ...

Implement __attribute__((objc_direct)), __attribute__((objc_direct_members))

__attribute__((objc_direct)) is an attribute on methods declaration, and
__attribute__((objc_direct_members)) on implemen

Implement __attribute__((objc_direct)), __attribute__((objc_direct_members))

__attribute__((objc_direct)) is an attribute on methods declaration, and
__attribute__((objc_direct_members)) on implementation, categories or
extensions.

A `direct` property specifier is added (@property(direct) type name)

These attributes / specifiers cause the method to have no associated
Objective-C metadata (for the property or the method itself), and the
calling convention to be a direct C function call.

The symbol for the method has enforced hidden visibility and such direct
calls are hence unreachable cross image. An explicit C function must be
made if so desired to wrap them.

The implicit `self` and `_cmd` arguments are preserved, however to
maintain compatibility with the usual `objc_msgSend` semantics,
3 fundamental precautions are taken:

1) for instance methods, `self` is nil-checked. On arm64 backends this
typically adds a single instruction (cbz x0, <closest-ret>) to the
codegen, for the vast majority of the cases when the return type is a
scalar.

2) for class methods, because the class may not be realized/initialized
yet, a call to `[self self]` is emitted. When the proper deployment
target is used, this is optimized to `objc_opt_self(self)`.

However, long term we might want to emit something better that the
optimizer can reason about. When inlining kicks in, these calls
aren't optimized away as the optimizer has no idea that a single call
is really necessary.

3) the calling convention for the `_cmd` argument is changed: the caller
leaves the second argument to the call undefined, and the selector is
loaded inside the body when it's referenced only.

As far as error reporting goes, the compiler refuses:
- making any overloads direct,
- making an overload of a direct method,
- implementations marked as direct when the declaration in the
interface isn't (the other way around is allowed, as the direct
attribute is inherited from the declaration),
- marking methods required for protocol conformance as direct,
- messaging an unqualified `id` with a direct method,
- forming any @selector() expression with only direct selectors.

As warnings:
- any inconsistency of direct-related calling convention when
@selector() or messaging is used,
- forming any @selector() expression with a possibly direct selector.

Lastly an `objc_direct_members` attribute is added that can decorate
`@implementation` blocks and causes methods only declared there (and in
no `@interface`) to be automatically direct. When decorating an
`@interface` then all methods and properties declared in this block are
marked direct.

Radar-ID: rdar://problem/2684889
Differential Revision: https://reviews.llvm.org/D69991
Reviewed-By: John McCall

show more ...

Include the mangled name in -ast-dump=json

I am planning to use this feature to make update_cc_test_checks.py less fragile
by obtaining the mangled names directly from -ast-dump=json. Currently,
it

Include the mangled name in -ast-dump=json

I am planning to use this feature to make update_cc_test_checks.py less fragile
by obtaining the mangled names directly from -ast-dump=json. Currently,
it uses c-index-test which ignores the -triple=, etc. arguments that are
in the RUN: line and therefore does not generate checks for some targets.

The AST dump tests were updated using the following command:
`python $LLVM_BINDIR/gen_ast_dump_json_test.py --update --source $LLVM_SRC/clang/test/AST/*-json.*`

Reviewers: aaron.ballman

Reviewed By: aaron.ballman

Subscribers: rsmith, MaskRay, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D69564

show more ...