Previously `M-x mark-defun` and friends wouldn't work properly, and would
highlight something at the top of the buffer. This adds a regexp for top-level
functions so the defun functions should work as expected, and also adds a
regexp for extracting their name so which-function-mode should work now too.
Reviewed By: goldstein.w.n
Differential Revision: https://reviews.llvm.org/D158196
Lower formal arguments and returns for functions with the
`amdgpu_cs_chain` and `amdgpu_cs_chain_preserve` calling conventions:
* Put `inreg` arguments into SGPRs, starting at s0, and other arguments
into VGPRs, starting at v8. No arguments should end up on the stack, if
we don't have enough registers we should error out.
* Lower the return (which is always void) as an S_ENDPGM.
* Set the ScratchRSrc register to s48:51, as described in the docs.
* Set the SP to s32, matching amdgpu_gfx. This might be revisited in a
future patch.
Differential Revision: https://reviews.llvm.org/D153517
This patch is extracted from D96035, it adds support for the existing
DWARFLinker functionality. What is not supported yet:
1. Types deduplication(--odr mode).
2. Modules deduplication.
3. Generation of index tables.
Reland2: temporarily disabled call to "--linker llvm" for tls-variable.test
and location-expression.test as it does not work properly on bigendian
architecture.
Differential Revision: https://reviews.llvm.org/D153268
Prior to this change clang didn't emit missing-field-initializers
warning for designated initializers. The comments say that it is done to
match gcc behavior. However, gcc behaves so only for C. For C++ warnings
are emitted.
Fixes https://github.com/llvm/llvm-project/issues/56628
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D157879
Expand (s/z/any)ext instructions to be compatible with more
types for GlobalISel.
This patch mainly focuses on 64-bit and 128-bit vectors with
element size of powers of 2.
It also notably handles larger than legal vectors.
Differential Revision: https://reviews.llvm.org/D157113
This reverts commit 0229dd0626.
This introduces two test failures on s390x.
tools/dsymutil/X86/location-expression.test:
warning: cann't load line table.
note: while processing CU1
/builddir/build/BUILD/llvm-18.0.0.src/test/tools/dsymutil/X86/location-expression.test:20:10: error: CHECK: expected string not found in input
# CHECK: DW_AT_name{{.*}}"CU1"
^
<stdin>:34:32: note: scanning from here
0x0000000b: DW_TAG_compile_unit [1] *
^
<stdin>:37:2: note: possible intended match here
DW_AT_name [DW_FORM_strp] ( .debug_str[0x09000000] = )
^
tools/dsymutil/X86/tls-variable.test:
warning: cann't load line table.
note: while processing CU1
/builddir/build/BUILD/llvm-18.0.0.src/test/tools/dsymutil/X86/tls-variable.test:19:10: error: CHECK: expected string not found in input
# CHECK: DW_AT_name{{.*}}"CU1"
^
<stdin>:26:32: note: scanning from here
0x0000000b: DW_TAG_compile_unit
^
<stdin>:29:2: note: possible intended match here
DW_AT_name ()
^
BOLT uses MCAsmLayout to calculate the output values of basic blocks.
This means output values are calculated based on a pre-linking state and
any changes to symbol values during linking will cause incorrect values
to be used.
This issue was first addressed in D154604 by adding all basic block
symbols to the symbol table for the linker to resolve them. However, the
runtime overhead of handling this huge symbol table turned out to be
prohibitively large.
This patch solves the issue in a different way. First, a temporary
section containing [input address, output symbol] pairs is emitted to the
intermediary object file. The linker will resolve all these references
so we end up with a section of [input address, output address] pairs.
This section is then parsed and used to:
- Replace BinaryBasicBlock::OffsetTranslationTable
- Replace BinaryFunction::InputOffsetToAddressMap
- Update BinaryBasicBlock::OutputAddressRange
Note that the reason this is more performant than the previous attempt
is that these symbol references do not cause entries to be added to the
symbol table. Instead, section-relative references are used for the
relocations.
Reviewed By: maksfb
Differential Revision: https://reviews.llvm.org/D155604
The `STGloop` family of pseudo-instructions all expand to a loop which
iterates over a region of memory setting all its MTE tags to a given
value. The loop writes to the flags in order to check termination. But
the unexpanded pseudo-instructions were not marked as modifying the
flags. Therefore it was possible for one to end up in a location where
the flags were live, and then the loop would corrupt them.
We spotted the effect of this in a libc++ test involving a lot of
complicated inlining, and haven't been able to construct a smaller
test case that demonstrates actual incorrect output code. So my test
here is just checking that `implicit-def $nzcv` shows up on the
pseudo-instructions as they're output from isel.
Reviewed By: DavidSpickett
Differential Revision: https://reviews.llvm.org/D158262
83a06997c6 broke this test but
we only saw the failure on a subset of the flang bots because
it requires 3 target backends, and most of ours only enable AArch64.
Use %if to run as much of the test as we can with the targets
we have.
Reviewed By: awarzynski
Differential Revision: https://reviews.llvm.org/D158264
When an expression is instantiated, TreeTransform skips ImplicitCastExpr
nodes, assuming they are recreated when the instantiated expression is
built. It breaks functions that use non-default floating-point options,
because they are kept in these ImplicitCastExprs. In this case the
recreated ImplicitCastExpr takes FP options from the current Sema state
and not from AST node.
To fix this issue the FP options in Sema object are set when a compound
statement is cloned in TreeTransform.
This change fixes https://github.com/llvm/llvm-project/issues/64605
([Regression 16 -> 17] Template instantiation ignores FENV_ACCESS being
ON for both definition and instantiation).
Differential Revision: https://reviews.llvm.org/D158158
When the 'int Four = Two;' is sunk into the 'case 0:' block,
the debug value for 'Three' is set incorrectly to 'poison'.
Reviewed By: aprantl
Differential Revision: https://reviews.llvm.org/D158171
Binary and decimal values were reconginzed by strtoll, which returns
error when the msb is 1, and the error was ignored, resulting to wrong
results.
This patch fixes the issue.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D157079
This patch adds lowering support for threadprivate
variables encapsulated in a common block and
marked inside a copyin clause.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D157083
Currently clangd will display useless inlay hint for dependent type in
structured binding, e.g.
```
template <class T>
void foobar(T arg) {
auto [a/*: <dependent type>*/, b/*: <dependent type>*/] = arg;
}
```
Differential Revision: https://reviews.llvm.org/D157956
The testcases mainly cover three situations:
- the arguments which should be immediates are non immediates.
- the immediate is out of upper limit of the argument type.
- the immediate is out of lower limit of the argument type.
Depends on D155829
Reviewed By: SixWeining
Differential Revision: https://reviews.llvm.org/D157570
The function emitFunctionEntryLabel does not look at whether or not a function is a leaf when setting the entry flags,
and instead blindly marks all functions as non-leaf routines. Change it to check if a function is a leaf function and
mark it accordingly.
Use raw strings instead of regular strings when escapes are used for
regex matches or arbitrary letters rather than C-style characters.
This fixes `SyntaxWarning`s:
```
TestRunner.py:205: SyntaxWarning: invalid escape sequence '\c'
"""
TestRunner.py:1566: SyntaxWarning: invalid escape sequence '\s'
match = _caching_re_compile("^\s*%else\s*(%{)?").search(ln)
```
Differential Revision: https://reviews.llvm.org/D158356
This change contains the initial support of FastMath flag in complex dialect. Similar to what we did in [Arith dialect](https://reviews.llvm.org/rGb56e65d31825fe4a1ae02fdcbad58bb7993d63a7), `fastmath` attributes in the complex dialect are directly mapped to the corresponding LLVM fastmath flags.
In this diff,
- Definition of FastMathAttr as a custom attribute in the Complex dialect that inherits from the EnumAttr class.
- Definition of ComplexFastMathInterface, which is an interface that is implemented by operations that have a complex::fastmath attribute.
- Declaration of a default-valued fastmath attribute for unary and arithmetic operations in the Complex dialect.
- Conversion code to lower arithmetic fastmath flags to LLVM fastmath flags
NOT in this diff (but planned and progressively implemented):
- Documentation of flag meanings
- Support the fastmath flag conversion to Arith dialect
- Folding/rewrite implementations that are enabled by fastmath flags (although it's the original motivation to support the flag)
RFC: https://discourse.llvm.org/t/rfc-fastmath-flags-support-in-complex-dialect/71981
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D156310
Check for 'wasm.' prefix before proceeding, and a bit of common handling
for some of the intrinsics therein.
Reviewed By: nikic
Differential Revision: https://reviews.llvm.org/D158370
All dependencies on code from LoopVectorize.cpp have been
removed/refactored. Move the ::execute implementations to other recipe
definitions in VPlanRecipes.cpp
This patch removes the `getBBIDOrNumber` which was introduced to allow emitting version 1.
Reviewed By: shenhan
Differential Revision: https://reviews.llvm.org/D158299
This is useful when user already have partially-scf'ed IR or other ops with nested regions (e.g. linalg.generic).
Also, improve error message and pass docs.
Differential Revision: https://reviews.llvm.org/D158349
