[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 ...

Implemented [[clang::musttail]] attribute for guaranteed tail calls.

This is a Clang-only change and depends on the existing "musttail"
support already implemented in LLVM.

The [[clang::musttail]]

Implemented [[clang::musttail]] attribute for guaranteed tail calls.

This is a Clang-only change and depends on the existing "musttail"
support already implemented in LLVM.

The [[clang::musttail]] attribute goes on a return statement, not
a function definition. There are several constraints that the user
must follow when using [[clang::musttail]], and these constraints
are verified by Sema.

Tail calls are supported on regular function calls, calls through a
function pointer, member function calls, and even pointer to member.

Future work would be to throw a warning if a users tries to pass
a pointer or reference to a local variable through a musttail call.

Reviewed By: rsmith

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

show more ...

[CodeGen] Simplify the way lifetime of block captures is extended

Rather than pushing inactive cleanups for the block captures at the
entry of a full expression and activating them during the creati

[CodeGen] Simplify the way lifetime of block captures is extended

Rather than pushing inactive cleanups for the block captures at the
entry of a full expression and activating them during the creation of
the block literal, just call pushLifetimeExtendedDestroy to ensure the
cleanups are popped at the end of the scope enclosing the block
expression.

rdar://problem/63996471

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

show more ...

[Windows SEH] Fix abnormal-exits in _try

Summary:
Per Windows SEH Spec, except _leave, all other early exits of a _try (goto/return/continue/break) are considered abnormal exits. In those cases, th

[Windows SEH] Fix abnormal-exits in _try

Summary:
Per Windows SEH Spec, except _leave, all other early exits of a _try (goto/return/continue/break) are considered abnormal exits. In those cases, the first parameter passes to its _finally funclet should be TRUE to indicate an abnormal-termination.

One way to implement abnormal exits in _try is to invoke Windows runtime _local_unwind() (MSVC approach) that will invoke _dtor funclet where abnormal-termination flag is always TRUE when calling _finally. Obviously this approach is less optimal and is complicated to implement in Clang.

Clang today has a NormalCleanupDestSlot mechanism to dispatch multiple exits at the end of _try. Since _leave (or try-end fall-through) is always Indexed with 0 in that NormalCleanupDestSlot, this fix takes the advantage of that mechanism and just passes NormalCleanupDest ID as 1st Arg to _finally.

Reviewers: rnk, eli.friedman, JosephTremoulet, asmith, efriedma

Reviewed By: efriedma

Subscribers: efriedma, cfe-commits

Tags: #clang

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

show more ...

Revert "EHScopeStack::Cleanup has virtual functions so the destructor should be too."

This type was already well designed - having a protected destructor, and
derived classes being final/public non-

Revert "EHScopeStack::Cleanup has virtual functions so the destructor should be too."

This type was already well designed - having a protected destructor, and
derived classes being final/public non-virtual destructors, the type
couldn't be destroyed polymorphically & accidentally cause slicing.

This reverts commit 736385c0b49d42f398ffa1458883f0d182178ef4.

show more ...

EHScopeStack::Cleanup has virtual functions so the destructor should be too.

Fixes cppcheck warning.

Replace llvm::integer_sequence and friends with the C++14 standard version

The implementation in libc++ takes O(1) compile time, ours was O(n).

llvm-svn: 368990

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the ne

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636

show more ...

Spelling mistakes in comments. NFCI. (PR27635)

llvm-svn: 299083

Retire llvm::alignOf in favor of C++11 alignof.

No functionality change intended.

llvm-svn: 284730

[Temporary, Lifetime] Add lifetime marks for temporaries

With all MaterializeTemporaryExprs coming with a ExprWithCleanups, it's
easy to add correct lifetime.end marks into the right RunCleanupsScop

[Temporary, Lifetime] Add lifetime marks for temporaries

With all MaterializeTemporaryExprs coming with a ExprWithCleanups, it's
easy to add correct lifetime.end marks into the right RunCleanupsScope.

Differential Revision: http://reviews.llvm.org/D20499

llvm-svn: 274385

show more ...

[CodeGen] Emit lifetime.end intrinsic after objects are destructed in
landing pads.

Previously, lifetime.end intrinsics were inserted only on normal control
flows. This prevented StackColoring from

[CodeGen] Emit lifetime.end intrinsic after objects are destructed in
landing pads.

Previously, lifetime.end intrinsics were inserted only on normal control
flows. This prevented StackColoring from merging stack slots for objects
that were destroyed on the exception handling control flow since it
couldn't tell their lifetime ranges were disjoint. This patch fixes
code-gen to emit the intrinsic on both control flows.

rdar://problem/22181976

Differential Revision: http://reviews.llvm.org/D18196

llvm-svn: 265197

show more ...

Update clang to use the updated LLVM EH instructions

Depends on D15139.

Reviewers: rnk

Differential Revision: http://reviews.llvm.org/D15140

llvm-svn: 255423

[CodeGen] Remove dead code. NFC.

llvm-svn: 250418

[SEH] Use cleanupendpad so that WinEHPrepare gets the coloring right

Cleanupendpad is a lot like catchendpad, so we can reuse the same
EHScopeStack type.

llvm-svn: 247349

Devirtualize EHScopeStack::Cleanup's dtor because it's never destroyed polymorphically

llvm-svn: 245378

Fix for MSVC

llvm-svn: 245368

Wdeprecated: Support movability of EHScopeStack::Cleanup objects as they are move constructed in ConditionalCleanup::restore

llvm-svn: 245367

[MS ABI] Hook clang up to the new EH instructions

The new EH instructions make it possible for LLVM to generate .xdata
tables that the MSVC personality routines will be happy about. Because
this is

[MS ABI] Hook clang up to the new EH instructions

The new EH instructions make it possible for LLVM to generate .xdata
tables that the MSVC personality routines will be happy about. Because
this is experimental, hide it behind a -cc1 flag (-fnew-ms-eh).

Differential Revision: http://reviews.llvm.org/D11405

llvm-svn: 243767

show more ...

Hopefully fix android i386 build after r242554.

That platform has alignof(uint64_t) == 4, but, since LLVM_ALIGNAS(...)
cannot take anything but literal integers due to MSVC limitations, the
literal

Hopefully fix android i386 build after r242554.

That platform has alignof(uint64_t) == 4, but, since LLVM_ALIGNAS(...)
cannot take anything but literal integers due to MSVC limitations, the
literal '8' used there didn't match. Switch ScopeStackAlignment to
just use 8, as well.

llvm-svn: 242578

show more ...

Fix alignment issues in Clang.

Some const-correctness changes snuck in here too, since they were in the
area of code I was modifying.

This seems to make Clang actually work without Bus Error on
32b

Fix alignment issues in Clang.

Some const-correctness changes snuck in here too, since they were in the
area of code I was modifying.

This seems to make Clang actually work without Bus Error on
32bit-sparc.

Follow-up patches will factor out a trailing-object helper class, to
make classes using the idiom of appending objects to other objects
easier to understand, and to ensure (with static_assert) that required
alignment guarantees continue to hold.

Differential Revision: http://reviews.llvm.org/D10272

llvm-svn: 242554

show more ...

Revert "Revert r234581, it might have caused a few miscompiles in Chromium."

This reverts commit r234700. It turns out that the lifetime markers
were not the cause of Chromium failing but a bug whi

Revert "Revert r234581, it might have caused a few miscompiles in Chromium."

This reverts commit r234700. It turns out that the lifetime markers
were not the cause of Chromium failing but a bug which was uncovered by
optimizations exposed by the markers.

llvm-svn: 235553

show more ...

Revert r234581, it might have caused a few miscompiles in Chromium.

If the revert helps, I'll get a repro this Monday. Else I'll put the change
back in.

llvm-svn: 234700

Remove threshold for inserting lifetime markers for named temporaries

Now that TailRecursionElimination has been fixed with r222354, the
threshold on size for lifetime marker insertion can be remove

Remove threshold for inserting lifetime markers for named temporaries

Now that TailRecursionElimination has been fixed with r222354, the
threshold on size for lifetime marker insertion can be removed. This
only affects named temporary though, as the patch for unnamed temporaries
is still in progress.

My previous commit (r222993) was not handling debuginfo correctly, but
this could only be seen with some asan tests. Basically, lifetime markers
are just instrumentation for the compiler's usage and should not affect
debug information; however, the cleanup infrastructure was assuming it
contained only destructors, i.e. actual code to be executed, and was
setting the breakpoint for the end of the function to the closing '}', and
not the return statement, in order to show some destructors have been
called when leaving the function. This is wrong when the cleanups are only
lifetime markers, and this is now fixed.

llvm-svn: 234581

show more ...

Disambiguate call for GCC.

llvm-svn: 232122