[LLVM] Make more use of IRBuilder::CreateIntrinsic. NFC. (#112546)

Convert almost every instance of:
CreateCall(Intrinsic::getOrInsertDeclaration(...), ...)
to the equivalent CreateIntrinsic cal

[LLVM] Make more use of IRBuilder::CreateIntrinsic. NFC. (#112546)

Convert almost every instance of:
CreateCall(Intrinsic::getOrInsertDeclaration(...), ...)
to the equivalent CreateIntrinsic call.

show more ...

[NFC] Rename `Intrinsic::getDeclaration` to `getOrInsertDeclaration` (#111752)

Rename the function to reflect its correct behavior and to be consistent
with `Module::getOrInsertFunction`. This is a

[NFC] Rename `Intrinsic::getDeclaration` to `getOrInsertDeclaration` (#111752)

Rename the function to reflect its correct behavior and to be consistent
with `Module::getOrInsertFunction`. This is also in preparation of
adding a new `Intrinsic::getDeclaration` that will have behavior similar
to `Module::getFunction` (i.e, just lookup, no creation).

show more ...

[IRBuilder] Remove uses of CreateGlobalStringPtr() (NFC)

Since the migration to opaque pointers, CreateGlobalStringPtr()
is the same as CreateGlobalString(). Normalize to the latter.

[CodeGen] Port `StackProtector` to new pass manager (#75334)

The original `StackProtector` is both transform and analysis pass, break
it into two passes now. `getAnalysis<StackProtector>()` could b

[CodeGen] Port `StackProtector` to new pass manager (#75334)

The original `StackProtector` is both transform and analysis pass, break
it into two passes now. `getAnalysis<StackProtector>()` could be now
replaced by `FAM.getResult<SSPLayoutAnalysis>(F)` in new pass system.

show more ...

[llvm][TypeSize] Fix addition/subtraction in TypeSize. (#72979)

It seems TypeSize is currently broken in the sense that:

TypeSize::Fixed(4) + TypeSize::Scalable(4) => TypeSize::Fixed(8)

with

[llvm][TypeSize] Fix addition/subtraction in TypeSize. (#72979)

It seems TypeSize is currently broken in the sense that:

TypeSize::Fixed(4) + TypeSize::Scalable(4) => TypeSize::Fixed(8)

without failing its assert that explicitly tests for this case:

assert(LHS.Scalable == RHS.Scalable && ...);

The reason this fails is that `Scalable` is a static method of class
TypeSize,
and LHS and RHS are both objects of class TypeSize. So this is
evaluating
if the pointer to the function Scalable == the pointer to the function
Scalable,
which is always true because LHS and RHS have the same class.

This patch fixes the issue by renaming `TypeSize::Scalable` ->
`TypeSize::getScalable`, as well as `TypeSize::Fixed` to
`TypeSize::getFixed`,
so that it no longer clashes with the variable in
FixedOrScalableQuantity.

The new methods now also better match the coding standard, which
specifies that:
* Variable names should be nouns (as they represent state)
* Function names should be verb phrases (as they represent actions)

show more ...

[CodeGen] Drop some references to getInt8PtrTy. NFC

Similar to https://reviews.llvm.org/D157550

[NFC] Remove Type::getInt8PtrTy (#71029)

Replace this with PointerType::getUnqual().
Followup to the opaque pointer transition. Fixes an in-code TODO item.

[Analysis] Add Scalable field in MemoryLocation.h (#69716)

This is the first of a series of patch to improve Alias Analysis on
Scalable quantities.
Keep Scalable information from TypeSize whic

[Analysis] Add Scalable field in MemoryLocation.h (#69716)

This is the first of a series of patch to improve Alias Analysis on
Scalable quantities.
Keep Scalable information from TypeSize which
will be used in Alias Analysis.

show more ...

[StackProtector] don't check stack protector before calling nounwind functions

https://reviews.llvm.org/rGd656ae28095726830f9beb8dbd4d69f5144ef821
introduced a additional checks before calling noret

[StackProtector] don't check stack protector before calling nounwind functions

https://reviews.llvm.org/rGd656ae28095726830f9beb8dbd4d69f5144ef821
introduced a additional checks before calling noreturn functions in
response to this security paper related to Catch Handler Oriented
Programming (CHOP):
https://download.vusec.net/papers/chop_ndss23.pdf
See also:
https://bugs.chromium.org/p/llvm/issues/detail?id=30

This causes stack canaries to be inserted in C code which was
unexpected; we noticed certain Linux kernel trees stopped booting after
this (in functions trying to initialize the stack canary itself).
https://github.com/ClangBuiltLinux/linux/issues/1815

There is no point checking the stack canary like this when exceptions
are disabled (-fno-exceptions or function is marked noexcept) or for C
code. The GCC patch for this issue does something similar:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=a25982ada523689c8745d7fb4b1b93c8f5dab2e7

Android measured a 2% regression in RSS as a result of d656ae280957 and
undid it globally:
https://android-review.googlesource.com/c/platform/build/soong/+/2524336

Reviewed By: xiangzhangllvm

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

show more ...

[StackProtector] attribute __stack_chk_fail as NoReturn

When GCC added support for stack smashing protections, it was defined
that:

> This hook returns a CALL_EXPR that alerts the runtime that the

[StackProtector] attribute __stack_chk_fail as NoReturn

When GCC added support for stack smashing protections, it was defined
that:

> This hook returns a CALL_EXPR that alerts the runtime that the stack
> protect guard variable has been modified. This expression should
> involve a call to a noreturn function.
> The default version of this hook invokes a function called
> ‘__stack_chk_fail’, taking no arguments.

Do so as well for __stack_smash_handler for OpenBSD.

Every libc implementation I could find has __stack_chk_fail marked
noreturn, or the implementation calls abort, exit, or panic (which
themselves are noreturn).

Glibc: https://sourceware.org/git/?p=glibc.git;a=blob;f=debug/stack_chk_fail.c
Musl: https://git.musl-libc.org/cgit/musl/tree/src/env/__stack_chk_fail.c
Bionic: https://android.googlesource.com/platform/bionic/+/refs/heads/master/libc/bionic/__stack_chk_fail.cpp
FreeBSD: https://cgit.freebsd.org/src/tree/lib/libc/secure/stack_protector.c
OpenBSD: https://github.com/openbsd/src/blob/master/lib/libc/sys/stack_protector.c
NetBSD: https://github.com/NetBSD/src/blob/trunk/lib/libc/misc/stack_protector.c
Linux Kernel: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/panic.c
Apple: https://opensource.apple.com/source/Libc/Libc-1439.40.11/sys/OpenBSD/stack_protector.c.auto.html

Link: https://gcc.gnu.org/onlinedocs/gccint/Stack-Smashing-Protection.html#Stack-Smashing-Protection

This will later help us diagnose functions that fall through to other
functions vs end in calls to functions that are noreturn.

Reviewed By: efriedma

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

show more ...

StackProtector: expose RequiresStackProtector publicly. NFC.

Lift EHPersonalities from Analysis to IR (NFC)

Computing EH-related information was only relevant for analysis passes so far. Lifting it to IR will allow the IR Verifier to calculate EH funclet colo

Lift EHPersonalities from Analysis to IR (NFC)

Computing EH-related information was only relevant for analysis passes so far. Lifting it to IR will allow the IR Verifier to calculate EH funclet coloring and validate funclet operand bundles in a follow-up step.

Reviewed By: rnk, compnerd

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

show more ...

Add -disable-check-noreturn-call for stack protect

Differential Revision: https://reviews.llvm.org/D141556
Reviewed By: lanza

Revert D141134 "[NFC] Only expose getXXXSize functions in TypeSize"

The patch should be discussed further.

This reverts commit dd56e1c92b0e6e6be249f2d2dd40894e0417223f.

[NFC] Only expose getXXXSize functions in TypeSize

Currently 'TypeSize' exposes two functions that serve the same purpose:
- getFixedSize / getFixedValue
- getKnownMinSize / getKnownMinValue

sour

[NFC] Only expose getXXXSize functions in TypeSize

Currently 'TypeSize' exposes two functions that serve the same purpose:
- getFixedSize / getFixedValue
- getKnownMinSize / getKnownMinValue

source : https://github.com/llvm/llvm-project/blob/bf82070ea465969e9ae86a31dfcbf94c2a7b4c4c/llvm/include/llvm/Support/TypeSize.h#L337-L338

This patch offers to remove one of the two and stick to a single function in the code base.

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

show more ...

Attributes: Add function getter to parse integer string attributes

The most common case for string attributes parses them as integers. We
don't have a convenient way to do this, and as a result we h

Attributes: Add function getter to parse integer string attributes

The most common case for string attributes parses them as integers. We
don't have a convenient way to do this, and as a result we have
inconsistent missing attribute and invalid attribute handling
scattered around. We also have inconsistent radix usage to
getAsInteger; some places use the default 0 and others use base 10.

Update a few of the uses, but there are quite a lot of these.

show more ...

[StackProtector] Rewrite dominator tree update handling

Enhance stack protector

Reviewed By: LuoYuanke

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

Revert "Enhance stack protector for calling no return function"

This reverts commit 416e8c6ad529c57f21f46c6f52ded96d3ed239fb.

This commit causes a test failure with expensive checks due to a DT
ver

Revert "Enhance stack protector for calling no return function"

This reverts commit 416e8c6ad529c57f21f46c6f52ded96d3ed239fb.

This commit causes a test failure with expensive checks due to a DT
verification failure. Revert to bring bot back to green:

https://green.lab.llvm.org/green/job/clang-stage1-cmake-RA-expensive/24249/testReport/junit/LLVM/CodeGen_X86/stack_protector_no_return_ll/

+ /Users/buildslave/jenkins/workspace/clang-stage1-cmake-RA-expensive/clang-build/bin/llc /Users/buildslave/jenkins/workspace/clang-stage1-cmake-RA-expensive/llvm-project/llvm/test/CodeGen/X86/stack-protector-no-return.ll -mtriple=x86_64-unknown-linux-gnu -o -
+ /Users/buildslave/jenkins/workspace/clang-stage1-cmake-RA-expensive/clang-build/bin/FileCheck /Users/buildslave/jenkins/workspace/clang-stage1-cmake-RA-expensive/llvm-project/llvm/test/CodeGen/X86/stack-protector-no-return.ll
DominatorTree is different than a freshly computed one!
Current:
=============================--------------------------------
Inorder Dominator Tree: DFSNumbers invalid: 0 slow queries.
[1] %entry {4294967295,4294967295} [0]
[2] %unreachable {4294967295,4294967295} [1]
[2] %lpad {4294967295,4294967295} [1]
[3] %invoke.cont {4294967295,4294967295} [2]
[4] %invoke.cont2 {4294967295,4294967295} [3]
[4] %SP_return3 {4294967295,4294967295} [3]
[4] %CallStackCheckFailBlk2 {4294967295,4294967295} [3]
[3] %lpad1 {4294967295,4294967295} [2]
[4] %eh.resume {4294967295,4294967295} [3]
[5] %SP_return6 {4294967295,4294967295} [4]
[5] %CallStackCheckFailBlk5 {4294967295,4294967295} [4]
[4] %terminate.lpad {4294967295,4294967295} [3]
[5] %SP_return9 {4294967295,4294967295} [4]
[5] %CallStackCheckFailBlk8 {4294967295,4294967295} [4]
[2] %SP_return {4294967295,4294967295} [1]
[2] %CallStackCheckFailBlk {4294967295,4294967295} [1]
Roots: %entry

show more ...

MemoryLocation: convert Optional to std::optional

Enhance stack protector for calling no return function

Reviewed By: LuoYuanke, WangPengfei, lebedev.ri

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

StackProtector: ensure stack checks are inserted before the tail call

The IR stack protector pass should insert stack checks before the tail
calls not only the musttail calls. So that the attributes

StackProtector: ensure stack checks are inserted before the tail call

The IR stack protector pass should insert stack checks before the tail
calls not only the musttail calls. So that the attributes `ssqreq` and
`tail call`, which are emited by llvm-opt, could be both enabled by
llvm-llc.

Reviewed By: compnerd

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

show more ...

[llvm] Don't use Optional::hasValue (NFC)

Cleanup codegen includes

This is a (fixed) recommit of https://reviews.llvm.org/D121169

after: 1061034926
before: 1063332844

Discourse thread: https://discourse.llvm.org/t/include-what-you-use-in

Cleanup codegen includes

This is a (fixed) recommit of https://reviews.llvm.org/D121169

after: 1061034926
before: 1063332844

Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup
Differential Revision: https://reviews.llvm.org/D121681

show more ...

Revert "Cleanup codegen includes"

This reverts commit 7f230feeeac8a67b335f52bd2e900a05c6098f20.
Breaks CodeGenCUDA/link-device-bitcode.cu in check-clang,
and many LLVM tests, see comments on https:/

Revert "Cleanup codegen includes"

This reverts commit 7f230feeeac8a67b335f52bd2e900a05c6098f20.
Breaks CodeGenCUDA/link-device-bitcode.cu in check-clang,
and many LLVM tests, see comments on https://reviews.llvm.org/D121169

show more ...