[SanitizerBounds] Add support for NoSanitizeBounds function

Currently adding attribute no_sanitize("bounds") isn't disabling
-fsanitize=local-bounds (also enabled in -fsanitize=bounds). The Clang
fr

[SanitizerBounds] Add support for NoSanitizeBounds function

Currently adding attribute no_sanitize("bounds") isn't disabling
-fsanitize=local-bounds (also enabled in -fsanitize=bounds). The Clang
frontend handles fsanitize=array-bounds which can already be disabled by
no_sanitize("bounds"). However, instrumentation added by the
BoundsChecking pass in the middle-end cannot be disabled by the
attribute.

The fix is very similar to D102772 that added the ability to selectively
disable sanitizer pass on certain functions.

In this patch, if no_sanitize("bounds") is provided, an additional
function attribute (NoSanitizeBounds) is attached to IR to let the
BoundsChecking pass know we want to disable local-bounds checking. In
order to support this feature, the IR is extended (similar to D102772)
to make Clang able to preserve the information and let BoundsChecking
pass know bounds checking is disabled for certain function.

Reviewed By: melver

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

show more ...

[llvm][IR] Add no_cfi constant

With Control-Flow Integrity (CFI), the LowerTypeTests pass replaces
function references with CFI jump table references, which is a problem
for low-level code that need

[llvm][IR] Add no_cfi constant

With Control-Flow Integrity (CFI), the LowerTypeTests pass replaces
function references with CFI jump table references, which is a problem
for low-level code that needs the address of the actual function body.

For example, in the Linux kernel, the code that sets up interrupt
handlers needs to take the address of the interrupt handler function
instead of the CFI jump table, as the jump table may not even be mapped
into memory when an interrupt is triggered.

This change adds the no_cfi constant type, which wraps function
references in a value that LowerTypeTestsModule::replaceCfiUses does not
replace.

Link: https://github.com/ClangBuiltLinux/linux/issues/1353

Reviewed By: nickdesaulniers, pcc

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

show more ...

[Utils][vim] Add missing highlights for fast-math flags

This patch adds the `afn`, `contract`, and `reassoc` fast-math flags.

It also fixes up `fneg`'s order in the alphabetized list.

Reviewed By:

[Utils][vim] Add missing highlights for fast-math flags

This patch adds the `afn`, `contract`, and `reassoc` fast-math flags.

It also fixes up `fneg`'s order in the alphabetized list.

Reviewed By: MaskRay, craig.topper

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

show more ...

[Utils] Add missing freeze and poison keyword highlights

This patch adds missing keyword highlights for freeze and poison

Reviewed By: MaskRay, porglezomp

Differential Revision: https://reviews.ll

[Utils] Add missing freeze and poison keyword highlights

This patch adds missing keyword highlights for freeze and poison

Reviewed By: MaskRay, porglezomp

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

show more ...

[Utils][vim] Highlight 'ptr' type

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

[SanitizeCoverage] Add support for NoSanitizeCoverage function attribute

We really ought to support no_sanitize("coverage") in line with other
sanitizers. This came up again in discussions on the Li

[SanitizeCoverage] Add support for NoSanitizeCoverage function attribute

We really ought to support no_sanitize("coverage") in line with other
sanitizers. This came up again in discussions on the Linux-kernel
mailing lists, because we currently do workarounds using objtool to
remove coverage instrumentation. Since that support is only on x86, to
continue support coverage instrumentation on other architectures, we
must support selectively disabling coverage instrumentation via function
attributes.

Unfortunately, for SanitizeCoverage, it has not been implemented as a
sanitizer via fsanitize= and associated options in Sanitizers.def, but
rolls its own option fsanitize-coverage. This meant that we never got
"automatic" no_sanitize attribute support.

Implement no_sanitize attribute support by special-casing the string
"coverage" in the NoSanitizeAttr implementation. To keep the feature as
unintrusive to existing IR generation as possible, define a new negative
function attribute NoSanitizeCoverage to propagate the information
through to the instrumentation pass.

Fixes: https://bugs.llvm.org/show_bug.cgi?id=49035

Reviewed By: vitalybuka, morehouse

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

show more ...

[Utils][vim] Highlight CHECK-EMPTY: & CHECK-COUNT: directives

Reviewed By: porglezomp

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

IR/AArch64/X86: add "swifttailcc" calling convention.

Swift's new concurrency features are going to require guaranteed tail calls so
that they don't consume excessive amounts of stack space. This wo

IR/AArch64/X86: add "swifttailcc" calling convention.

Swift's new concurrency features are going to require guaranteed tail calls so
that they don't consume excessive amounts of stack space. This would normally
mean "tailcc", but there are also Swift-specific ABI desires that don't
naturally go along with "tailcc" so this adds another calling convention that's
the combination of "swiftcc" and "tailcc".

Support is added for AArch64 and X86 for now.

show more ...

[Utils][vim] Highlight 'vscale' constant

Reviewed By: awarzynski

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

[Utils][vim] Highlight `poison` keyword

Reviewed By: awarzynski, MaskRay

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

[Utils] Add missing attributes in syntax files

Added the following attributes to all LLVM syntax files:
* allocsize
* cold
* convergent
* dereferenceable_or_null
* hot
* inaccessiblemem_

[Utils] Add missing attributes in syntax files

Added the following attributes to all LLVM syntax files:
* allocsize
* cold
* convergent
* dereferenceable_or_null
* hot
* inaccessiblemem_or_argmemonly
* inaccessiblememonly
* inalloca
* jumptable
* nocallback
* nocf_check
* noduplicate
* nofree
* nomerge
* noprofile
* nosync
* null_pointer_is_valid
* optforfuzzing
* preallocated
* safestack
* sanitize_hwaddress
* sanitize_memtag
* shadowcallstack
* speculative_load_hardening
* swifterror
* syncscope
* tailcc
* willreturn

I generated that list by comparing:
* Attributes.inc (generated from Attributes.td), and
* the Vim syntax file: llvm/utils/vim/syntax/llvm.vim

My original intention was to focus on the Vim syntax file. Since other
syntax files are also out-of-date, I added these attributes (if missing)
to other files as well. Note that in the other sytnax files (i.e. for
Emacs, VScode and Kate), there will be other attributes missing too.

I've also sorted all attributes alphabetically. Otherwise it's really
hard to automate adding new attributes. And I think that it was the
original intent to keep all of them ordered alphabetically.

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

show more ...

[NFC] Add x86_amx and some missed half, bfloat keywords to llvm plugin syntaxes

Reviewed By: LuoYuanke

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

Revert "[IR] add fn attr for no_stack_protector; prevent inlining on mismatch"

This reverts commit b7926ce6d7a83cdf70c68d82bc3389c04009b841.

Going with a simpler approach.

[IR] add fn attr for no_stack_protector; prevent inlining on mismatch

It's currently ambiguous in IR whether the source language explicitly
did not want a stack a stack protector (in C, via function

[IR] add fn attr for no_stack_protector; prevent inlining on mismatch

It's currently ambiguous in IR whether the source language explicitly
did not want a stack a stack protector (in C, via function attribute
no_stack_protector) or doesn't care for any given function.

It's common for code that manipulates the stack via inline assembly or
that has to set up its own stack canary (such as the Linux kernel) would
like to avoid stack protectors in certain functions. In this case, we've
been bitten by numerous bugs where a callee with a stack protector is
inlined into an __attribute__((__no_stack_protector__)) caller, which
generally breaks the caller's assumptions about not having a stack
protector. LTO exacerbates the issue.

While developers can avoid this by putting all no_stack_protector
functions in one translation unit together and compiling those with
-fno-stack-protector, it's generally not very ergonomic or as
ergonomic as a function attribute, and still doesn't work for LTO. See also:
https://lore.kernel.org/linux-pm/[email protected]/
https://lore.kernel.org/lkml/[email protected]/T/#u

Typically, when inlining a callee into a caller, the caller will be
upgraded in its level of stack protection (see adjustCallerSSPLevel()).
By adding an explicit attribute in the IR when the function attribute is
used in the source language, we can now identify such cases and prevent
inlining. Block inlining when the callee and caller differ in the case that one
contains `nossp` when the other has `ssp`, `sspstrong`, or `sspreq`.

Fixes pr/47479.

Reviewed By: void

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

show more ...

[LangRef] Define mustprogress attribute

LLVM IR currently assumes some form of forward progress. This form is
not explicitly defined anywhere, and is the cause of miscompilations
in most languages t

[LangRef] Define mustprogress attribute

LLVM IR currently assumes some form of forward progress. This form is
not explicitly defined anywhere, and is the cause of miscompilations
in most languages that are not C++11 or later. This implicit forward progress
guarantee can not be opted out of on a function level nor on a loop
level. Languages such as C (C11 and later), C++ (pre-C++11), and Rust
have different forward progress requirements and this needs to be
evident in the IR.

Specifically, C11 and onwards (6.8.5, Paragraph 6) states that "An
iteration statement whose controlling expression is not a constant
expression, that performs no input/output operations, does not access
volatile objects, and performs no synchronization or atomic operations
in its body, controlling expression, or (in the case of for statement)
its expression-3, may be assumed by the implementation to terminate."
C++11 and onwards does not have this assumption, and instead assumes
that every thread must make progress as defined in [intro.progress] when
it comes to scheduling.

This was initially brought up in [0] as a bug, a solution was presented
in [1] which is the current workaround, and the predecessor to this
change was [2].

After defining a notion of forward progress for IR, there are two
options to address this:
1) Set the default to assuming Forward Progress and provide an opt-out for functions and an opt-in for loops.
2) Set the default to not assuming Forward Progress and provide an opt-in for functions, and an opt-in for loops.

Option 2) has been selected because only C++11 and onwards have a
forward progress requirement and it makes sense for them to opt-into it
via the defined `mustprogress` function attribute. The `mustprogress`
function attribute indicates that the function is required to make
forward progress as defined. This is sharply in contrast to the status
quo where this is implicitly assumed. In addition, `willreturn` implies `mustprogress`.

The background for why this definition was chosen is in [3] and for why
the option was chosen is in [4] and the corresponding thread(s). The implementation is in D85393, the
clang patch is in D86841, the LoopDeletion patch is in D86844, the
Inliner patches are in D87180 and D87262, and there will be more
incoming.

[0] https://bugs.llvm.org/show_bug.cgi?id=965#c25
[1] https://lists.llvm.org/pipermail/llvm-dev/2017-October/118558.html
[2] https://reviews.llvm.org/D65718
[3] https://lists.llvm.org/pipermail/llvm-dev/2020-September/144919.html
[4] https://lists.llvm.org/pipermail/llvm-dev/2020-September/145023.html

Reviewed By: jdoerfert, efriedma, nikic

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

show more ...

[Utils] Add highlighting definition for byref IR attribute

This patch assumes `byref` can be handled identically to `byval`.

Reviewed By: MaskRay

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

[Utils] Add highlighting definition for byref IR attribute

This patch assumes `byref` can be handled identically to `byval`.

Reviewed By: MaskRay

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

show more ...

[Utils] Add noundef attribute to vim/emacs/vscode syntax scripts

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

vim: add `bfloat` keyword

Highlight the `bfloat` type introduced in D78190.

[lit] Add builtin support for flaky tests in lit

This commit adds a new keyword in lit called ALLOW_RETRIES. This keyword
takes a single integer as an argument, and it allows the test to fail that
n

[lit] Add builtin support for flaky tests in lit

This commit adds a new keyword in lit called ALLOW_RETRIES. This keyword
takes a single integer as an argument, and it allows the test to fail that
number of times before it first succeeds.

This work attempts to make the existing test_retry_attempts more flexible
by allowing by-test customization, as well as eliminate libc++'s FLAKY_TEST
custom logic.

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

show more ...

[X86] Add new calling convention that guarantees tail call optimization

When the target option GuaranteedTailCallOpt is specified, calls with
the fastcc calling convention will be transformed into t

[X86] Add new calling convention that guarantees tail call optimization

When the target option GuaranteedTailCallOpt is specified, calls with
the fastcc calling convention will be transformed into tail calls if
they are in tail position. This diff adds a new calling convention,
tailcc, currently supported only on X86, which behaves the same way as
fastcc, except that the GuaranteedTailCallOpt flag does not need to
enabled in order to enable tail call optimization.

Patch by Dwight Guth <[email protected]>!

Reviewed By: lebedev.ri, paquette, rnk

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

llvm-svn: 373976

show more ...

vim: add `immarg` keyword

The `immarg` attribute was added in r355981.

llvm-svn: 370443

vim: `swiftself` is an attribute

Highlight the `swiftself` attribute on parameters.

llvm-svn: 354934

Implementation of asm-goto support in LLVM

This patch accompanies the RFC posted here:
http://lists.llvm.org/pipermail/llvm-dev/2018-October/127239.html

This patch adds a new CallBr IR instruction

Implementation of asm-goto support in LLVM

This patch accompanies the RFC posted here:
http://lists.llvm.org/pipermail/llvm-dev/2018-October/127239.html

This patch adds a new CallBr IR instruction to support asm-goto
inline assembly like gcc as used by the linux kernel. This
instruction is both a call instruction and a terminator
instruction with multiple successors. Only inline assembly
usage is supported today.

This also adds a new INLINEASM_BR opcode to SelectionDAG and
MachineIR to represent an INLINEASM block that is also
considered a terminator instruction.

There will likely be more bug fixes and optimizations to follow
this, but we felt it had reached a point where we would like to
switch to an incremental development model.

Patch by Craig Topper, Alexander Ivchenko, Mikhail Dvoretckii

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

llvm-svn: 353563

show more ...

Add fneg instruction to syntax highlighting lists

llvm-svn: 346785

vim: rename `singlethread` to `syncscope`

SVN r307722 renamed the keyword from `singlethread` to `syncscope`.
Update the syntax file accordingly.

llvm-svn: 328211