This patch replaces NoneType() and NoneType::None with None in
preparation for migration from llvm::Optional to std::optional.
In the std::optional world, we are not guranteed to be able to
default-construct std::nullopt_t or peek what's inside it, so neither
NoneType() nor NoneType::None has a corresponding expression in the
std::optional world.
Once we consistently use None, we should even be able to replace the
contents of llvm/include/llvm/ADT/None.h with something like:
using NoneType = std::nullopt_t;
inline constexpr std::nullopt_t None = std::nullopt;
to ease the migration from llvm::Optional to std::optional.
Differential Revision: https://reviews.llvm.org/D138376
Clang language-level address spaces and LLVM pointer address spaces are
not the same thing (even though they will both have a numeric value of
zero in many cases). LangAS is a enum class to avoid implicit conversions,
but eba69b59d1 avoided the compiler error by
adding a `static_cast<>`. While touching this code, simplify it by using
CreatePointerBitCastOrAddrSpaceCast() which is already a no-op if the types
match.
This changes the code generation for spir64 to place the globals in
the sycl_global addreds space, which maps to `addrspace(1)`.
Reviewed By: bader
Differential Revision: https://reviews.llvm.org/D138284
This patch gives basic parsing and semantic analysis support for 'strict'
modifier with 'num_tasks' clause of 'taskloop' construct introduced in
OpenMP 5.1 (section 2.12.2)
Differential Revision: https://reviews.llvm.org/D138328
Checks for builtins for the following instructions were aded:
V6_v6mpyhubs10
V6_v6mpyhubs10_vxx
V6_v6mpyvubs10
V6_v6mpyvubs10_vxx
V6_vlutvvbi
V6_vlutvvb_oracci
V6_vlutvwhi
V6_vlutvwh_oracci
Summary:
AIX library functions frexpl(), ldexpl(), and modfl() are for 128-bit IBM long double, i.e. __ibm128. Other *l() functions, e.g., acosl(), are for 64-bit long double. The AIX Clang compiler currently maps builtin functions __builtin_frexpl(), __builtin_ldexpl(), and __builtin_modfl() to frexpl(), ldexpl(), and modfl() in 64-bit long double mode which results in seg-faults or incorrect return values. This patch changes to map __builtin_frexpl(), __builtin_ldexpl(), and __builtin_modfl() to double version lib functions frexp(), ldexp() and modf() in 64-bit long double mode.
Reviewed by: hubert.reinterpretcast, daltenty
Differential Revision: https://reviews.llvm.org/D137986
This matches OpenBSD, and it supports Swift's use of clang for its C interop
functionality. Recent changes to Swift use AddClangSystemIncludeArgs() to
inspect the cc1 args; this doesn't work for platforms where cc1 adds standard
include paths implicitly. See:
<cf3354222d>
Also clean up InitHeaderSearch, making it clearer which targets manage header
search paths in the driver.
Differential Revision: https://reviews.llvm.org/D138183
Enable using -module-summary with -S
(similarly to what currently can be achieved with opt <input> -o - | llvm-dis).
This is a recommit of ef9e62469.
Test plan: ninja check-all
Differential revision: https://reviews.llvm.org/D137768
This patch gives basic parsing and semantic analysis support for 'strict'
modifier with 'grainsize' clause of 'taskloop' construct introduced in
OpenMP 5.1 (section 2.12.2)
Differential Revision: https://reviews.llvm.org/D138217
It is meaningless to emit macro definitions for named modules. With some
small experiments, the size of the module for the named modules reduced
2%~4% after this patch.
Currently there is a -emit-header-module mode, which can combine several
headers together as a module interface. However, this breaks our
assumption (for standard c++ modules) about module interface. The module
interface should come from a module interface unit. And if it is a
header, it should be a header unit. And currently we have no ideas to
combine several headers together.
So I think this mode is an experimental one and it is not maintained and
it is not used. So it will be better to remove them.
Reviewed By: Bigcheese, dblaikie, bruno
Differential Revision: https://reviews.llvm.org/D137609
-ffp-model=strict -ffp-model=fast will still enable strict exception
handling behavior, therefore clang still emits constrained FP operations
in IR.
-ffp-model=fast -ffp-model=strict emits two warnings: one for strict
overriding fast, the other for strict overriding strict, which is
confusing.
Reviewed By: zahiraam
Differential Revision: https://reviews.llvm.org/D137618
When during parsing we encountered a duplicate `ObjCProtocolDecl`, we
were always emitting an error. With this change we accept
* when a previous `ObjCProtocolDecl` is in a hidden [sub]module;
* parsed `ObjCProtocolDecl` is the same as the previous one.
And in case of mismatches we provide more detailed error messages.
rdar://93069080
Differential Revision: https://reviews.llvm.org/D130327
This diff splits out (from LLVMCore) IR printing passes into IRPrinter.
This structure is similar to what we already have for IRReader and
enables us to avoid circular dependencies between LLVMCore and Analysis
(this is a preparation for https://reviews.llvm.org/D137768).
The legacy interface is left unchanged, once the legacy pass manager
is removed (in the future) we will be able to clean it up further.
The bazel build configuration has been updated as well.
Test plan:
1/ Tested the following cmake configurations: static/dynamic linking * lld/gold * clang/gcc
2/ bazel build --config=generic_clang @llvm-project//...
Differential revision: https://reviews.llvm.org/D138081
This reverts commit eb2a57ebc7.
llvm/include/llvm/Transforms/Instrumentation/KCFI.h including
llvm/CodeGen is a layering violation. We should use an approach where
Instrumementation/ doesn't need to include CodeGen/.
Sorry for not spotting this in the review.
This avoids depending on int->float or double->float conversion.
Improving codegen with #pragma STDC FENV_ACCESS ON.
Really we should improve constant folding somewhere, but this was
a cheap and easy improvement.
Fixes PR59052.
The KCFI sanitizer emits "kcfi" operand bundles to indirect
call instructions, which the LLVM back-end lowers into an
architecture-specific type check with a known machine instruction
sequence. Currently, KCFI operand bundle lowering is supported only
on 64-bit X86 and AArch64 architectures.
As a lightweight forward-edge CFI implementation that doesn't
require LTO is also useful for non-Linux low-level targets on
other machine architectures, add a generic KCFI operand bundle
lowering pass that's only used when back-end lowering support is not
available and allows -fsanitize=kcfi to be enabled in Clang on all
architectures.
Reviewed By: nickdesaulniers, MaskRay
Differential Revision: https://reviews.llvm.org/D135411
When a pcm has already been loaded from disk, reuse it from the
InMemoryModuleCache in readASTFileControlBlock. This avoids potentially
reading it again.
As noted in the FIXME, ideally we would also add the module to the cache
if it will be used again later, but that could modify its build state
and we do not have enough context currenlty to know if it's correct.
Differential Revision: https://reviews.llvm.org/D138160
Refactor StaticAnalyzer to use clang::SarifDocumentWriter for
serializing sarif diagnostics.
Uses clang::SarifDocumentWriter to generate SARIF output in the
StaticAnalyzer.
Various bugfixes are also made to clang::SarifDocumentWriter.
Summary of changes:
clang/lib/Basic/Sarif.cpp:
* Fix bug in adjustColumnPos introduced from prev move, it now uses
FullSourceLoc::getDecomposedExpansionLoc which provides the correct
location (in the presence of macros) instead of
FullSourceLoc::getDecomposedLoc.
* Fix createTextRegion so that it handles caret ranges correctly,
this should bring it to parity with the previous implementation.
clang/test/Analysis/diagnostics/Inputs/expected-sarif:
* Update the schema URL to the offical website
* Add the emitted defaultConfiguration sections to all rules
* Annotate results with the "level" property
clang/lib/StaticAnalyzer/Core/SarifDiagnostics.cpp:
* Update SarifDiagnostics class to hold a clang::SarifDocumentWriter
that it uses to convert diagnostics to SARIF.
Add support for this GCC option which has the purpose of disallowing text
relative accesses of module local symbols with PIC. In effect, this changes
the code model to "medium".
Reviewed By: uweigand, efriedma, MaskRay
Differential Revision: https://reviews.llvm.org/D137044
Use FastEvaluateAsRValue() in EvaluateAsConstantExpr() as well, to
short-circuit evaluation of simple integrals.
Differential Revision: https://reviews.llvm.org/D138115
This change breaks no existing tests but does fix the linked issue.
Declarations of operator overloads are annotated with
`TT_FunctionDeclarationName` on the `operator` keyword, which is already
being checked for when aligning, so the extra `kw_operator` doesn't seem
to be necessary. (just for reference, it was added in
rG92b397fb9d55ccdf4632c2b1b15b4a0ee417cf74 / 92b397fb9d)
Fixes https://github.com/llvm/llvm-project/issues/55733
Reviewed By: HazardyKnusperkeks, owenpan
Differential Revision: https://reviews.llvm.org/D137223
I'm not exactly sure what the intent of that section of
`spaceRequiredBetween` is doing, it seems to handle templates and <<,
but the part which adds spaces before parens is way later, as part
of `spaceRequiredBeforeParens`.
Fixes https://github.com/llvm/llvm-project/issues/58821
Reviewed By: HazardyKnusperkeks, owenpan, MyDeveloperDay
Differential Revision: https://reviews.llvm.org/D137474
Integer-to-float conversion was handled in constant evaluator with
default rounding mode. This change fixes the behavior and the conversion
is made using rounding mode stored in ImplicitCastExpr node.
Differential Revision: https://reviews.llvm.org/D137719
This change exposes the sin library function for HLSL,
excluding long, int, and long long doubles.
Sin is supported for all scalar, vector, and matrix types.
Long and long long double support is missing in this patch because those types
don't exist in HLSL. Int is missing because the sin function only works on floating type arguments.
The full documentation of the HLSL sin function is available here:
https://docs.microsoft.com/en-us/windows/win32/direct3dhlsl/dx-graphics-hlsl-sin
Reviewed By: python3kgae
Differential Revision: https://reviews.llvm.org/D138161
A scalar which exceeds 4 bytes should be returned via a stack slot,
on an AVRTiny device.
Reviewed By: aykevl
Differential Revision: https://reviews.llvm.org/D138125
We were crashing trying to convert a GlobalDecl from a
CXXConstructorDecl. Instead of trying to do that conversion, just pass
down the original GlobalDecl.
I think we could actually compute the correct constructor/destructor
kind from the context, given the way Microsoft mangling works, but it's
simpler to just pass through the correct constructor/destructor kind.
Differential Revision: https://reviews.llvm.org/D136776
Previously, Itanium ABI guard variables were set after initialization was
complete for non-block declared variables with static and thread storage
duration. That resulted in initialization of such variables being restarted
in cases where the variable was referenced while it was still under
construction. Per C++20 [class.cdtor]p2, such references are permitted
(though the value obtained by such an access is unspecified). The late
initialization resulted in recursive reinitialization loops for cases like
this:
template<typename T>
struct ct {
struct mc {
mc() { ct<T>::smf(); }
void mf() const {}
};
thread_local static mc tlsdm;
static void smf() { tlsdm.mf(); }
};
template<typename T>
thread_local typename ct<T>::mc ct<T>::tlsdm;
int main() {
ct<int>::smf();
}
With this change, guard variables are set before initialization is started
so as to avoid such reinitialization loops.
Fixes https://github.com/llvm/llvm-project/issues/57828
Reviewed By: rjmccall
Differential Revision: https://reviews.llvm.org/D135919
This change exposes the cos library function for HLSL,
excluding long, int, and long long doubles.
Cos is supported for all scalar, vector, and matrix types.
Long and long long double support is missing in this patch because those types
don't exist in HLSL. Int is missing because the cos function only works on floating type arguments.
The full documentation of the HLSL cos function is available here:
https://docs.microsoft.com/en-us/windows/win32/direct3dhlsl/dx-graphics-hlsl-cos
Reviewed By: python3kgae
Differential Revision: https://reviews.llvm.org/D134921
This is a follow-up to 53c98d85a, which made the same change but only
for GNU. It seems that we should try to provide a consistent behavior
across all targets.
This fixes an issue where clang/test/Driver/nostdincxx.cpp would start
failing on non-GNU targets because that test was too loose in its checks.
It would only check that 'file not found' was part of the error message,
but didn't ensure that the file we had not found was <vector>.
Differential Revision: https://reviews.llvm.org/D138062
More work for temp.friend p9, this fixes a previous bug where we didn't
properly consider a friend to depend on the enclosing template if it
only did so via an NTTP.
Only reset "NeedsCleaning" flag in case of re-entrant call.
Do not needlessly blank IdentifierInfo. This information will be set
once the token type is picked.
This yields a nice 1% speedup when pre-processing sqlite amalgamation
through:
valgrind --tool=callgrind ./bin/clang -E sqlite3.c -o/dev/null
Differential Revision: https://reviews.llvm.org/D137960
This patch allows users to configure clang with option
e.g. `-DCLANG_CONFIG_FILE_USER_DIR=~/.config/clang` or invoke clang
with `--config-user-dir=~/.config/clang`.
Patch merged on behalf of @paperchalice (LJC)
Differential Revision: https://reviews.llvm.org/D136940
Users may partition parameters specified by configuration file and put
different groups into separate files. These files are inserted into the
main file using constructs `@file`. Relative file names in it are
resolved relative to the including configuration file and this is not
convenient in some cases. A configuration file, which resides in system
directory, may need to include a file with user-defined parameters and
still provide default definitions if such file is absent.
To solve such problems, the option `--config=` is allowed inside
configuration files. Like `@file` it results in insertion of
command-line arguments but the algorithm of file search is different and
allows overriding system definitions with user ones.
Differential Revision: https://reviews.llvm.org/D136354
ExtVectorElementExpr
This fixes a bug where an lvalue ExtVectorElementExpr was created when
the base expression was an ObjC property dot operator.
This reverts 220d08d942.
Differential Revision: https://reviews.llvm.org/D138058
This change would allow extension of new categories be aware of adding
more code here.
This patch also updates the comments, which was originally missing the
vector predicate.
Reviewed By: mikerice
Differential Revision: https://reviews.llvm.org/D137570
Error directive is allowed in both declared and executable contexts.
The function ActOnOpenMPAtClause is called in both places during the
parsers.
Adding a param "bool InExContext" to identify context which is used to
emit error massage.
Differential Revision: https://reviews.llvm.org/D137851
Use a FileEntryRef when retrieving modulemap paths in the scanner so
that we use a path compatible with the original module import, rather
than a FileEntry which can allow unrelated modules to leak paths into
how we build a module due to FileManager mutating the path.
Note: the current change prevents an "unrelated" path, but does not
change how VFS mapped paths are handled (which would be calling
getNameAsRequested) nor canonicalize the path.
Differential Revision: https://reviews.llvm.org/D137989
Currently Sema::CheckForIntOverflow misses several case that other compilers
diagnose for overflow in integral constant expressions. This includes the
arguments of a CXXConstructExpr as well as the expressions used in an
ArraySubscriptExpr, CXXNewExpr and CompoundLiteralExpr.
This fixes https://github.com/llvm/llvm-project/issues/58944
Differential Revision: https://reviews.llvm.org/D137897
NVIDIA, ARM, and Intel recently introduced two new FP8 formats, as described in the paper: https://arxiv.org/abs/2209.05433. The first of the two FP8 dtypes, E5M2, was added in https://reviews.llvm.org/D133823. This change adds the second of the two: E4M3.
There is an RFC for adding the FP8 dtypes here: https://discourse.llvm.org/t/rfc-add-apfloat-and-mlir-type-support-for-fp8-e5m2/65279. I spoke with the RFC's author, Stella, and she gave me the go ahead to implement the E4M3 type. The name of the E4M3 type in APFloat is Float8E4M3FN, as discussed in the RFC. The "FN" means only Finite and NaN values are supported.
Unlike E5M2, E4M3 has different behavior from IEEE types in regards to Inf and NaN values. There are no Inf values, and NaN is represented when the exponent and mantissa bits are all 1s. To represent these differences in APFloat, I added an enum field, fltNonfiniteBehavior, to the fltSemantics struct. The possible enum values are IEEE754 and NanOnly. Only Float8E4M3FN has the NanOnly behavior.
After this change is submitted, I plan on adding the Float8E4M3FN type to MLIR, in the same way as E5M2 was added in https://reviews.llvm.org/D133823.
Reviewed By: bkramer
Differential Revision: https://reviews.llvm.org/D137760
This macro is defined in avr-gcc, and is very useful especially in
assembly code to check whether particular instructions are supported. It
is also the basis for other macros like __AVR_HAVE_ELPM__.
Differential Revision: https://reviews.llvm.org/D137521
This simplifies the code by avoiding some special cases for family names
(as opposed to device names).
Differential Revision: https://reviews.llvm.org/D137520
I noticed that the values for __{CLANG,GCC}_ATOMIC_POINTER_LOCK_FREE were
incorrectly set to 1 instead of two in downstream CHERI targets because
pointers are handled specially there. While fixing this downstream, I
noticed that the existing code could be refactored to use
TargetInfo::hasBuiltinAtomic instead of repeating the almost identical
logic. In theory there could be a difference here since hasBuiltinAtomic() also
returns true for types less than 1 char in size, but since
InitializePredefinedMacros() never passes such a value this change should
not introduce any functional changes.
Reviewed By: rprichard, efriedma
Differential Revision: https://reviews.llvm.org/D135142
Dotdots were removed only when converting a relative path to absolute
one. This patch makes the behaviour consistent for absolute file paths by
removing them in that case as well. Also updates the documentation to mention
the behaviour.
Fixes https://github.com/clangd/clangd/issues/1317
Differential Revision: https://reviews.llvm.org/D137962
global module fragment
[basic.stc.dynamic.general]p2 says:
> The library provides default definitions for the global allocation
> and deallocation functions. Some global allocation and
> deallocation
> functions are replaceable ([new.delete]); these are attached to
> the global module ([module.unit]).
But we didn't take this before and the implicitly generated functions
will live in the module purview if we're compiling a module unit. This
is bad since the owning module will affect the linkage of the
declarations. This patch addresses this.
Closes https://github.com/llvm/llvm-project/issues/58560
The conditions for which Clang emits the `unsafe-fp-math` function
attribute has been modified as part of
`84a9ec2ff1ee97fd7e8ed988f5e7b197aab84a7`.
In the backend code generators `"unsafe-fp-math"="true"` enable floating
point contraction for the whole function.
The intent of the change in `84a9ec2ff1ee97fd7e8ed988f5e7b197aab84a7`
was to prevent backend code generators performing contractions when that
is not expected.
However the change is inaccurate and incomplete because it allows
`unsafe-fp-math` to be set also when only in-statement contraction is
allowed.
Consider the following example
```
float foo(float a, float b, float c) {
float tmp = a * b;
return tmp + c;
}
```
and compile it with the command line
```
clang -fno-math-errno -funsafe-math-optimizations -ffp-contract=on \
-O2 -mavx512f -S -o -
```
The resulting assembly has a `vfmadd213ss` instruction which corresponds
to a fused multiply-add. From the user perspective there shouldn't be
any contraction because the multiplication and the addition are not in
the same statement.
The optimized IR is:
```
define float @test(float noundef %a, float noundef %b, float noundef %c) #0 {
%mul = fmul reassoc nsz arcp afn float %b, %a
%add = fadd reassoc nsz arcp afn float %mul, %c
ret float %add
}
attributes #0 = {
[...]
"no-signed-zeros-fp-math"="true"
"no-trapping-math"="true"
[...]
"unsafe-fp-math"="true"
}
```
The `"unsafe-fp-math"="true"` function attribute allows the backend code
generator to perform `(fadd (fmul a, b), c) -> (fmadd a, b, c)`.
In the current IR representation there is no way to determine the
statement boundaries from the original source code.
Because of this for in-statement only contraction the generated IR
doesn't have instructions with the `contract` fast-math flag and
`llvm.fmuladd` is being used to represent contractions opportunities
that occur within a single statement.
Therefore `"unsafe-fp-math"="true"` can only be emitted when contraction
across statements is allowed.
Moreover the change in `84a9ec2ff1ee97fd7e8ed988f5e7b197aab84a7` doesn't
take into account that the floating point math function attributes can
be refined during IR code generation of a function to handle the cases
where the floating point math options are modified within a compound
statement via pragmas (see `CGFPOptionsRAII`).
For consistency `unsafe-fp-math` needs to be disabled if the contraction
mode for any scope/operation is not `fast`.
Similarly for consistency reason the initialization of `UnsafeFPMath` of
in `TargetOptions` for the backend code generation should take into
account the contraction mode as well.
Reviewed By: zahiraam
Differential Revision: https://reviews.llvm.org/D136786
This reverts commit bf8381a8bc.
There is a layering violation: LLVMAnalysis depends on LLVMCore, so
LLVMCore should not include LLVMAnalysis header
llvm/Analysis/ModuleSummaryAnalysis.h
Enable using -module-summary with -S
(similarly to what currently can be achieved with opt <input> -o - | llvm-dis).
This is a recommit of ef9e62469.
Test plan: ninja check-all
Differential revision: https://reviews.llvm.org/D137768
Enable using -module-summary with -S
(similarly to what currently can be achieved with opt <input> -o - | llvm-dis).
Test plan: ninja check-all
Differential revision: https://reviews.llvm.org/D137768
Move these to the new PM if they're used there.
Part of removing the legacy pass manager for optimization pipeline.
Reland with UseNewGVN usage in clang removed.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D137915
This patch removes getOrCreateInternalVariable from Clang OMP CodeGen and replaces it's uses with OMPBuilder::getOrCreateInternalVariable. Also refactors OMPBuilder::getOrCreateInternalVariable to change type of name from Twine to StringRef
Differential Revision: https://reviews.llvm.org/D137720
We plan to reuse it in the include-cleaner library, this patch moves
this functionality from clangd to libtooling, so that this piece of code can be
shared among all clang tools.
Differential Revision: https://reviews.llvm.org/D137697
It is helpful to know whih macro definition is emitted in the module
file without openning it directly. And this is not easy to be tested
with the lit test. So this patch add the facility to emit macro
definitions in `-module-file-info` action. And this should be innnocent
for every other cases.
Ran into an issue where function declarations inside function
scopes or uses of sizeof inside a function would treat the && in
'sizeof(Type &&)' as a binary operator.
Attempt to fix this by assuming reference when followed by ',' or
')'. Also adds tests for these.
Also hit an edge case in another test that treated "and" the same
as "&&" since it parses as C++. Changed the "and" to "also" so it
is no longer a keyword.
Fixes#58923.
Differential Revision: https://reviews.llvm.org/D137755
flag. But the driver checks for 'fno-math-errno' before passing
'funsafe-math-optimizations' to the FE. In GCC, the option
'funsafe-math-optimizations' doesn't affect the 'fmath-errno' flag.
This patch aligns clang with GCC.
'-ffast-math' sets the FPContract to 'fast'. But 'funsafe-math-optimizations'
the driver doesn't consider the FPContract when handling the option.
Unfortunately there are places in the BE that interpret unsafe math
mode as allowing FMA. This patch makes -ffast-math' and
'funsafe-math-optimizations' behave similarly in regard to the setting of the
FPContract.
Differential Revision: https://reviews.llvm.org/D137578
Add codegen for llvm cos and sin elementwise builtins
The sin and cos elementwise builtins are necessary for HLSL codegen.
Tests were added to make sure that the expected errors are encountered
when these functions are given inputs of incompatible types.
The new builtins are restricted to floating point types only.
Reviewed By: craig.topper, fhahn
Differential Revision: https://reviews.llvm.org/D135011
If true, colons in ASM parameters will be placed after line breaks.
true:
asm volatile("string",
:
: val);
false:
asm volatile("string", : : val);
Differential Revision: https://reviews.llvm.org/D91950
Improve checking for the standard layout type when diagnosing
the kernel argument with templated types. The check doesn't work
correctly for references or pointers due to the lazy template
instantiation.
Current fix only improves cases where nested types in the templates
do not depend on the template parameters.
Differential Revision: https://reviews.llvm.org/D134445
This patch adds the -fpass-plugin option to flang which dynamically loads LLVM
passes from the shared object passed as the argument to the flag. The behavior
of the option is designed to replicate that of the same option in clang and
thus has the same capabilities and limitations.
Features:
Multiple instances of -fpass-plugin=path-to-file can be specified and each
of the files will be loaded in that order.
The flag can be passed to both flang-new and flang-new -fc1.
The flag will be listed when the -help flag is passed to both flang-new and
flang-new -fc1. It will also be listed when the --help-hidden flag is passed.
Limitations:
Dynamically loaded plugins are not supported in clang on Windows and are not
supported in flang either.
Addenda:
Some minor stylistic changes are made in the files that were modified to
enable this functionality. Those changes make the naming of functions more
consistent, but do not change any functionality that is not directly
related to enabling -fpass-plugin.
Differential Revision: https://reviews.llvm.org/D129156
Define below macros according to LoongArch toolchain conventions [1].
* `__loongarch_grlen`
* `__loongarch_frlen`
* `__loongarch_lp64`
* `__loongarch_hard_float`
* `__loongarch_soft_float`
* `__loongarch_single_float`
* `__loongarch_double_float`
Note:
1. `__loongarch__` has been defined in earlier patch.
2. `__loongarch_arch` is not defined because I don't know how `TargetInfo` can get the arch name specified by `-march`.
3. `__loongarch_tune` will be defined in future.
[1]: https://loongson.github.io/LoongArch-Documentation/LoongArch-toolchain-conventions-EN.html
Depends on D136146
Differential Revision: https://reviews.llvm.org/D136413
On targets where ptrdiff_t is smaller than long, clang crashes when emitting
synthesized getters/setters that call objc_[gs]etProperty. Explicitly emit a
zext/trunc of the ivar offset value (which is defined to long) to ptrdiff_t,
which objc_[gs]etProperty takes.
Add a test using the AVR target, where ptrdiff_t is smaller than long. Test
failed previously and passes now.
Differential Revision: https://reviews.llvm.org/D112049
We now skip the destruction of array elements for `delete[] p`,
if the value of `p` is UnknownVal and does not have corresponding region.
This eliminate the crash in `getDynamicElementCount` on that
region and matches the behavior for deleting the array of
non-constant range.
Reviewed By: isuckatcs
Differential Revision: https://reviews.llvm.org/D136671
This is very backend specific so either belongs in Toolchains/ARM or in
ARMTargetParser. Since it is used in lldb, ARMTargetParser made more sense.
This is part of an effort to move information about ARM/AArch64 architecture
versions, extensions and CPUs into their respective TargetParsers.
Differential Revision: https://reviews.llvm.org/D137564
Reverted in 98fa95492f.
The Assignment Tracking debug-info feature is outlined in this RFC:
https://discourse.llvm.org/t/
rfc-assignment-tracking-a-better-way-of-specifying-variable-locations-in-ir
This patch plumbs the AssignmentTrackingPass (AKA declare-to-assign), added in
the previous patch in this set, into the optimisation pipeline from
clang. clang/test/CodeGen/assignment-tracking/assignment-tracking.cpp is the
main test for this patch.
Note: while clang (with the help of the declare-to-assign pass) can now emit
Assignment Tracking metadata, the llvm middle and back ends don't yet
understand it.
Reviewed By: jmorse
Differential Revision: https://reviews.llvm.org/D132226
For `-foo=bar`, getSpelling return `-foo=` which is exactly what we need from
the diagnostic. Drop `-` from the err_drv_unsupported_option_argument template.
This change makes `--` long option diagnostics more convenient.
Reviewed By: lenary
Differential Revision: https://reviews.llvm.org/D137659
I've:
- Sorted the members of FormatStyle alphabetical. The enums and structs
are kept close to the member.
- Sorted the yaml io functions, based on the type they operate on.
- Sorted the initializers in getLLVMStyle(), except that penalities are
kept at the end.
- Sorted the io of FormatStyle, this changes the --dump-config behavior.
- Moved the deprecated options into the only input case, this also
changes --dump-config, it does not put the not directly used options
in the .clang-format anymore.
- Sorted the comparisons in operator==.
- Added WhiteSpaceMacros in operator==, I've not actively looked if all
other members are compared.
- This showed flawed tests (or in my opinion a flawed io operation, but
that is another discussion and change).
Differential Revision: https://reviews.llvm.org/D137409
D133848 added support for the GCC format of target("..") attributes. The
supported formats to match gcc are:
// "arch=<arch>" - parsed to features as per -march=..
// "cpu=<cpu>" - parsed to features as per -mcpu=.., with CPU set to <cpu>
// "tune=<cpu>" - TuneCPU set to <cpu>
// "+feature", "+nofeature" - Add (or remove) feature.
We also support the existing formats, previously accepted by clang, for
compatibility with the existing code and intrinsics code:
// "feature", "no-feature" - Add (or remove) feature.
The clang formats would accept and use internal feature names
("fullfp16"/"neon"/"sve") as opposed to the user facing names
("fp16"/"simd"/"sve"). Usually they use the same names, but can be
different for cases like fp, fullfp16 and mte (among others).
This patch makes the clang format also except the user facing names, by
parsing the features through getArchExtFeature. There is a fallback if
the name is not recognized (like "fullfp16"), where we add the existing
string which should then be checked later for consistency. This allows
the internal names to be used as before, so long as they are recognized
as internal names. (Note that we currently don't have an implementation
of isValidFeatureName. The backend will currently give an error like
"'-sid' is not a recognized feature for this target (ignoring feature)."
This should be improved in a later patch once an implementation of
isValidFeatureName in clang is present).
Differential Revision: https://reviews.llvm.org/D137617
The glibc uses the define to avoid namespace polution on headers
that requires variadic argument, where the inclusion of stdarg.h is
required to obtain the va_list definition.
For such cases only __gnuc_va_list is required.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D137268
The Assignment Tracking debug-info feature is outlined in this RFC:
https://discourse.llvm.org/t/
rfc-assignment-tracking-a-better-way-of-specifying-variable-locations-in-ir
This patch plumbs the AssignmentTrackingPass (AKA declare-to-assign), added in
the previous patch in this set, into the optimisation pipeline from
clang. clang/test/CodeGen/assignment-tracking/assignment-tracking.cpp is the
main test for this patch.
Note: while clang (with the help of the declare-to-assign pass) can now emit
Assignment Tracking metadata, the llvm middle and back ends don't yet
understand it.
Reviewed By: jmorse
Differential Revision: https://reviews.llvm.org/D132226
This revision fixes typos where there are 2 consecutive words which are
duplicated. There should be no code changes in this revision (only
changes to comments and docs). Do let me know if there are any
undesirable changes in this revision. Thanks.
This patch enable `-sample-profile-use-profi` in Clang frontend as user-facing
feature. By using this patch, we can use the cflag of `-fsample-profile-use-profi`
instead of `-mllvm -sample-profile-use-profi`.
Reviewed By: hans, MaskRay
Differential Revision: https://reviews.llvm.org/D136846
Clang supports indirect call Control-Flow Integrity (CFI) sanitizers
(e.g. -fsanitize=cfi-icall), which enforce an exact type match
between a function pointer and the target function. Unfortunately,
Clang doesn't provide diagnostics that help developers avoid
function pointer assignments that can lead to runtime CFI
failures. -Wincompatible-function-pointer-types doesn't warn about
enum to integer mismatches if the types are otherwise compatible, for
example, which isn't sufficient with CFI.
Add -Wincompatible-function-pointer-types-strict, which checks for a
stricter function type compatibility in assignments and helps warn about
assignments that can potentially lead to CFI failures.
Reviewed By: aaron.ballman, nickdesaulniers
Differential Revision: https://reviews.llvm.org/D136790
This change makes `this` a reference instead of a pointer in
HLSL. HLSL does not have the `->` operator, and accesses through `this`
are with the `.` syntax.
Tests were added and altered to make sure
the AST accurately reflects the types.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D135721
Explicitly call `LLVMContext::setOpaquePointers` in `CodeGenAction`
before loading any IR files. With this we use the mode specified on the
command-line rather than lazily initializing it based on the contents of
the IR.
This helps when using `-fthinlto-index` which may end up mixing files
with typed and opaque pointer types which fails when the first file
happened to use typed pointers since we cannot downgrade IR with opaque
pointer types to typed pointer types.
Differential Revision: https://reviews.llvm.org/D137475
This was done as a test for D137302 and it makes sense to push these changes
Reviewed By: shafik
Differential Revision: https://reviews.llvm.org/D137491
Adds a 'targetFallback' field to relationships in symbol graph that
contains the plain name of the relationship target. This is useful for
clients when the relationship target symbol is not available.
Differential Revision: https://reviews.llvm.org/D136455
Before, when emitting a regular integer constant, we went:
Int -> APInt -> int -> emit
Fix this by using regular integer constants in emitConst() and instead
converting APInt to those once.
Before this patch code like this:
```
if (Class* obj{getObject()}) { }
```
would be mis-formated since the * would be annotated as a
binaryoperator.
This patch changes the * to become a PointerOrReference instead
and fixes the formatting issues.
Reviewed By: HazardyKnusperkeks
Differential Revision: https://reviews.llvm.org/D137327
This was confusing. InitElem peeks a pointer, while InitElemPop will
pop the pointer. However, for fields, InitField would pop the pointer
and no InitFieldPop exists. At least make InitField and InitElem behave
the same.
If we don't need the result anyway, use StorePop, instead of a Store+Pop
combination. That way we save one instruction and not using the result
is the common case anyway.
We may need hosted Clang/LLVM to compile and `getHostCpuName`
can be used for native detection.
Tests are added in riscv-cpus.c just like what AArch64/PPC
have done.
Reviewed By: kito-cheng
Differential Revision: https://reviews.llvm.org/D136930
The lowercase __ppc64__ is not defined by non-darwin GCC, therefore it lures
users to write code which is not portable to GCC. Migrate to __powerpc64__ in
preparation for undefining __ppc64__. __powerpc64__ is much more common than
__PPC64__.
It is caused by regenerate captured var value when processing the
has_device_addr, the captured var value has been generated in
GenerateOpenMPCapturedVars and passed as Arg in generateInfoForCapture.
The fix just use Arg instead regenerated just same as is_device_ptr
same line. Cases such as those in the associated lit tests, can now be
supported.
This adds a 'Count' field to TargetRegionEntryInfo to differentiate
regions with the same source position.
The OffloadEntriesInfoManager routines are updated to maintain a count of
regions seen at a location. The registration of regions proceeds that same as
before, but now the next available count is always determined and used in the
offload entry.
Fixes: https://github.com/llvm/llvm-project/issues/52707
Differential Revision: https://reviews.llvm.org/D134816
Only add the option processing and store the result. No attributes are
added to FIR yet.
Clang only forwards -mreassociate
if (AssociativeMath && !SignedZeros && !TrappingMath)
Flang doesn't have -f[no-]trapping-math, so this part of the condition
has been omitted. !TrappingMath is the default.
Differential Revision: https://reviews.llvm.org/D137329
Implement https://cplusplus.github.io/CWG/issues/2631.html.
Immediate calls in default arguments and defaults members
are not evaluated.
Instead, we evaluate them when constructing a
`CXXDefaultArgExpr`/`BuildCXXDefaultInitExpr`.
The immediate calls are executed by doing a
transform on the initializing expression.
Note that lambdas are not considering subexpressions so
we do not need to transform them.
As a result of this patch, unused default member
initializers are not considered odr-used, and
errors about members binding to local variables
in an outer scope only surface at the point
where a constructor is defined.
Reviewed By: aaron.ballman, #clang-language-wg
Differential Revision: https://reviews.llvm.org/D136554
This switches everything to use the memory attribute proposed in
https://discourse.llvm.org/t/rfc-unify-memory-effect-attributes/65579.
The old argmemonly, inaccessiblememonly and inaccessiblemem_or_argmemonly
attributes are dropped. The readnone, readonly and writeonly attributes
are restricted to parameters only.
The old attributes are auto-upgraded both in bitcode and IR.
The bitcode upgrade is a policy requirement that has to be retained
indefinitely. The IR upgrade is mainly there so it's not necessary
to update all tests using memory attributes in this patch, which
is already large enough. We could drop that part after migrating
tests, or retain it longer term, to make it easier to import IR
from older LLVM versions.
High-level Function/CallBase APIs like doesNotAccessMemory() or
setDoesNotAccessMemory() are mapped transparently to the memory
attribute. Code that directly manipulates attributes (e.g. via
AttributeList) on the other hand needs to switch to working with
the memory attribute instead.
Differential Revision: https://reviews.llvm.org/D135780
D124866 seem to have had an unintended side effect: __noinline__ on lambdas was no longer accepted.
This fixes the regression and adds a test case for it.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D137251
Implement https://cplusplus.github.io/CWG/issues/2631.html.
Immediate calls in default arguments and defaults members
are not evaluated.
Instead, we evaluate them when constructing a
`CXXDefaultArgExpr`/`BuildCXXDefaultInitExpr`.
The immediate calls are executed by doing a
transform on the initializing expression.
Note that lambdas are not considering subexpressions so
we do not need to transform them.
As a result of this patch, unused default member
initializers are not considered odr-used, and
errors about members binding to local variables
in an outer scope only surface at the point
where a constructor is defined.
Reviewed By: aaron.ballman, #clang-language-wg
Differential Revision: https://reviews.llvm.org/D136554
Intel Control-flow Enforcement Technology (CET) provides new instructions `endbr32/64` for the indirect branch control. They are NOPs on i686 and new targets. We need to check for that in case it crashes on older targets.
Fixes#58737
Reviewed By: nickdesaulniers
Differential Revision: https://reviews.llvm.org/D137317
Currently, the API for a model's custom value comparison returns a
boolean. Therefore, models cannot distinguish between situations where the
values are recognized by the model and different and those where the values are
just not recognized. This patch changes the return value to a tri-valued enum,
allowing models to express "don't know".
This patch is essentially a NFC -- no practical differences result from this
change in this patch. But, it prepares for future patches (particularly,
upcoming patches for widening) which will take advantage of the new flexibility.
Differential Revision: https://reviews.llvm.org/D137334
This matches other C++ drivers e.g. Linux that define
_GNU_SOURCE. This lets clang compiler more code by default
without explicitly passing _GNU_SOURCE on command line.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D136712
This patch moves the createOffloadEntriesAndInfoMetadata to OpenMPIRBuilder,
the createOffloadEntry helper function. The clang specific error handling is
invoked using a callback. This code will also be used by flang in the future.
[module.unit]p1 specifies that module and import are invalid components
of a module name, that module names cannot contain reserved
identifiers, and that std followed by zero or more digits is reserved.
The first issue (module and import pseudo-keywords) requires a
diagnostic, the second issue (use of reserved identifiers) does not
require a diagnostic. We diagnose both the same -- the code is ill-
formed unless the module declaration is in a system "header". This
allows STL implementations to use the reserved module names while
preventing users from stealing them out from under us.
Differential Revision: https://reviews.llvm.org/D136953
They were annotated with TrailingAnnotation, which they are not. And
that resulted in some quirky formatting in some cases.
Differential Revision: https://reviews.llvm.org/D136635
Without the patch UnwrappedLineFormatter::analyzeSolutionSpace just ran
out of possible formattings and would put everything just on one line.
The problem was that the the line break was forbidden, but putting the
conditional colon on the same line is also forbidden.
Differential Revision: https://reviews.llvm.org/D135918
Only add the option processing and store the result. No attributes are
added to FIR yet.
This patch follows Clang in forwarding -fno-honor-infinities as
-menable-no-infs.
Reviewed By: kiranchandramohan awarzynski vzakhari
Differential Revision: https://reviews.llvm.org/D137072
arm_neon_sve_bridge.h is not generated, so the rules which ensure the
generated files get copied into the installation prefix don't apply to
this one.
Add it to the aarch64_only_files set instead, which ensures it ends up
both in the build directory and the installation directory.
Tested with build targets `clang-resource-headers` and
`install-clang-resource-headers`.
Differential Revision: https://reviews.llvm.org/D137239
This enables odr indicators on all platforms and private aliases on non-Windows.
Note that GCC also uses private aliases: this fixes bogus
`The following global variable is not properly aligned.` errors for interposed global variables
Fix https://github.com/google/sanitizers/issues/398
Fix https://github.com/google/sanitizers/issues/1017
Fix https://github.com/llvm/llvm-project/issues/36893 (we can restore D46665)
Global variables of non-hasExactDefinition() linkages (i.e.
linkonce/linkonce_odr/weak/weak_odr/common/external_weak) are not instrumented.
If an instrumented variable gets interposed to an uninstrumented variable due to
symbol interposition (e.g. in issue 36893, _ZTS1A in foo.so is resolved to _ZTS1A in
the executable), there may be a bogus error.
With private aliases, the register code will not resolve to a definition in
another module, and thus prevent the issue.
Cons: minor size increase. This is mainly due to extra `__odr_asan_gen_*` symbols.
(ELF) In addition, in relocatable files private aliases replace some relocations
referencing global symbols with .L symbols and may introduce some STT_SECTION symbols.
For lld, with -g0, the size increase is 0.07~0.09% for many configurations I
have tested: -O0, -O1, -O2, -O3, -O2 -ffunction-sections -fdata-sections
-Wl,--gc-sections. With -g1 or above, the size increase ratio will be even smaller.
This patch obsoletes D92078.
Don't migrate Windows for now: the static data member of a specialization
`std::num_put<char>::id` is a weak symbol, as well as its ODR indicator.
Unfortunately, link.exe (and lld without -lldmingw) generally doesn't support
duplicate weak definitions (weak symbols in different TUs likely pick different
defined external symbols and conflict).
Differential Revision: https://reviews.llvm.org/D137227
It's not necessary to redo the source file preprocessing for reproducing linker
crashes because we must have successfully created the object file by this point.
Skip this step, and also don't report the preprocessed source file or create
the clang invocation shell script. The latter is no longer sensible without the
preprocessed source, or helpful given the linker reproducer will have it's own
shell script.
Differential Revision: https://reviews.llvm.org/D137289
Per discussions in D128745, remove ClangABICompat checks for implementations
of DR692/DR1395/DR1432. This is a potentially breaking changes, so the release
note is updated accordingly.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D136120
If a function is renamed with `__asm__`, the name provided is the
exact symbol name, without any extra implicit symbol prefixes.
If the target does use symbol prefixes, the IR level symbol gets
an `\01` prefix to indicate that it's a literal symbol name to be
taken as is.
When a builtin function is specialized by providing an inline
version of it, that inline function is named `<funcname>.inline`.
When the base function has been renamed due to `__asm__`, the inline
function ends up named `<asmname>.inline`. Up to this point,
things did work as expected before.
However, for targets with symbol prefixes, one codepath that produced
the combined name `<asmname>.inline` used the mangled `asmname` with
`\01` prefix, while others didn't. This patch fixes this.
This fixes the combination of asm renamed builtin function, with
inline override of the function, on any target with symbol
prefixes (such as i386 windows and any Darwin target).
Differential Revision: https://reviews.llvm.org/D137073
The Assignment Tracking debug-info feature is outlined in this RFC:
https://discourse.llvm.org/t/
rfc-assignment-tracking-a-better-way-of-specifying-variable-locations-in-ir
Enable in clang: -Xclang -fexperimental-assignment-tracking
Enable in llvm tools: -experimental-assignment-tracking
When assignment tracking is enabled in clang it will pass on the flag to enable
the feature in lllvm. It's undefined behaviour to read IR that contains
assignment tracking metadata without specifying the feature flags.
Tests will come with later patches that add assignment tracking features.
Reviewed By: jmorse
Differential Revision: https://reviews.llvm.org/D132221
gnu17 and earlier modes automatically expose several POSIX C APIs, and
this was accidentally disabled for gnu2x in
7d644e1215.
This restores the behavior for gnu2x mode (without changing the
behavior in C standards modes instead of GNU modes).
Fixes#56607
The dependency scanner relies on the module map filtering logic in `ASTWriter`. The algorithm currently considers all system module maps affecting, which is not only sub-optimal, but can also cause failures when building a module explicitly (see attached test case).
This patch applies the same filtering logic to system module maps.
Reviewed By: Bigcheese
Differential Revision: https://reviews.llvm.org/D136007
In D106876, we stopped serializing module map files that didn't affect compilation of the current module.
However, since each `SourceLocation` is simply an offset into `SourceManager`'s global buffer of concatenated input files in, these need to be adjusted during serialization. Otherwise, they can incorrectly point after the buffer or into subsequent input file.
This patch starts adjusting `SourceLocation`s, `FileID`s and other `SourceManager` offsets in `ASTWriter`.
Reviewed By: dexonsmith
Differential Revision: https://reviews.llvm.org/D136624
This patch delays some `ASTWriter` logic until after we've checked whether the source location entry we're serializing as an affecting file or not.
Depends on D137214.
Reviewed By: dexonsmith
Differential Revision: https://reviews.llvm.org/D137216
This patch is a NFC prep for D136624, where we start adjusting offsets into `SourceManager`.
Depends on D137213.
Reviewed By: dexonsmith
Differential Revision: https://reviews.llvm.org/D137214
For pragma diagnostic mappings, we always write/read `SourceLocation` with offset 0. This is equivalent to just writing a `FileID`, which is exactly what this patch starts doing.
Depends on D137211.
Reviewed By: dexonsmith
Differential Revision: https://reviews.llvm.org/D137213
This patch adds new functions for writing/reading `FileID`s and uses them to replace some ad-hoc code.
Reviewed By: dexonsmith
Differential Revision: https://reviews.llvm.org/D137211
In https://reviews.llvm.org/D80833, there were concerns about
determinism emitting the commandline into CodeView. We're actually
hitting these when running clang-cl on Linux (cross compiling) versus on
Windows (e.g. -fmessage-length being inferred on terminals).
Add -g[no-]codeview-command-line to enable/disable this feature.
It's still on by default to preserve the current state of clang.
Reviewed By: thakis, rnk
Differential Revision: https://reviews.llvm.org/D136474
Based on discussion on the core reflector, it was made clear that a
concept that depends on itself should be a hard error, not a constraint
failure. This patch implements a stack of constraint-checks-in-progress
to make sure we quit, rather than hitting stack-exhaustion.
Note that we DO need to be careful to make sure we still check
constraints properly that are caused by a previous constraint, but not
derived from (such as when a check causes us to check special member
function generation), so we cannot use the existing logic to see if this
is being instantiated.
This fixes https://github.com/llvm/llvm-project/issues/44304 and
https://github.com/llvm/llvm-project/issues/50891.
Differential Revision: https://reviews.llvm.org/D136975
As reported in https://github.com/llvm/llvm-project/issues/49192,
we did a pretty poor job diagnosing cases where someone forgot 'auto', a
nd is probably in the middle of a variable declaration. This patch
makes us properly diagnose in cases where the next token is a reference,
or CVR qualifier.
For the following program,
$ cat t.c
struct t {
int (__attribute__((btf_type_tag("rcu"))) *f)();
int a;
};
int foo(struct t *arg) {
return arg->a;
}
Compiling with 'clang -g -O2 -S t.c' will cause a failure like below:
clang: /home/yhs/work/llvm-project/clang/lib/Sema/SemaType.cpp:6391: void {anonymous}::DeclaratorLocFiller::VisitParenTypeLoc(clang::ParenTypeLoc):
Assertion `Chunk.Kind == DeclaratorChunk::Paren' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
......
#5 0x00007f89e4280ea5 abort (/lib64/libc.so.6+0x21ea5)
#6 0x00007f89e4280d79 _nl_load_domain.cold.0 (/lib64/libc.so.6+0x21d79)
#7 0x00007f89e42a6456 (/lib64/libc.so.6+0x47456)
#8 0x00000000045c2596 GetTypeSourceInfoForDeclarator((anonymous namespace)::TypeProcessingState&, clang::QualType, clang::TypeSourceInfo*) SemaType.cpp:0:0
#9 0x00000000045ccfa5 GetFullTypeForDeclarator((anonymous namespace)::TypeProcessingState&, clang::QualType, clang::TypeSourceInfo*) SemaType.cpp:0:0
......
The reason of the failure is due to the mismatch of TypeLoc and D.getTypeObject().Kind. For example,
the TypeLoc is
BTFTagAttributedType 0x88614e0 'int btf_type_tag(rcu)()' sugar
|-ParenType 0x8861480 'int ()' sugar
| `-FunctionNoProtoType 0x8861450 'int ()' cdecl
| `-BuiltinType 0x87fd500 'int'
while corresponding D.getTypeObject().Kind points to DeclaratorChunk::Paren, and
this will cause later assertion.
To fix the issue, similar to AttributedTypeLoc, let us skip BTFTagAttributedTypeLoc in
GetTypeSourceInfoForDeclarator().
Differential Revision: https://reviews.llvm.org/D136807
We use getHostCPUFeatures in x86::getX86TargetFeatures so I think
this FIXME is taken care of already.
Reviewed By: RKSimon
Differential Revision: https://reviews.llvm.org/D137054
We only really need avx512bw for masking 256 or 512 bit GFNI
instructions due to the need for v32i1 or v64i1.
I wanted to enable 128-bit intrinsics with avx512vl, but the
__builtin_ia32_selectb_128 used in the header file requires avx512bw.
The codegen test for the same is also not using a masked instruction
because vselect with v16i1 mask and v16i8 is not legal so is expanded
before isel. To fix these issues we need a mask specific builtin and a
mask specific ISD opcode.
Fixes PR58687.
Reviewed By: pengfei
Differential Revision: https://reviews.llvm.org/D137036
This makes use of the changes introduced in D134604, in order to
instantiate alias templates witn a final sugared substitution.
This comes at no additional relevant cost.
Since we don't track / unique them in specializations, we wouldn't be
able to resugar them later anyway.
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Differential Revision: https://reviews.llvm.org/D136565
This makes use of the changes introduced in D134604, in order to
instantiate non-type template parameters and default template arguments
with a final sugared substitution.
This comes at no additional relevant cost.
Since we don't track / unique them in specializations, we wouldn't be
able to resugar them later anyway.
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Differential Revision: https://reviews.llvm.org/D136564
This fixes a problem where __va_list_tag was not correctly imported,
possibly leading to multiple definitions with different types.
This adds __va_list_tag to it's proper scope, so that the ASTImporter
can find it.
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Differential Revision: https://reviews.llvm.org/D136886
Re-apply of: 3d0e9edd8e
Reverted in: 0cb65b0a58
A function parameter was using the wrong type 'llvm::TargetRegion' instead of
'const llvm:: TargetRegion&', which caused the error in the address sanitizer.
The correct type is now used.
This patch puts the individual target region information attributes into a
struct so that the nested mappings are not needed and passing the information
around is simplified.
Reviewed By: jdoerfert, mikerice
Differential Revision: https://reviews.llvm.org/D136601
Only add the option processing and store the result. No attributes are
added to FIR yet.
Only the "off" and "fast" options are supported. "fast-honor-pragmas" is not applicable because we do not implement `#pragma clang fp contract()` in Fortran [1]. "on" is not supported because it is unclear how to fuse only within individual statements. gfortran also does not implement "on": treating it as an "off".
Currently the default value is "off" to preserve existing behavior. gfortran uses "fast" by default and that may be the right thing for flang-new after further discussion in the future, but that can be changed separately. gfortran's documentation is available [[ https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html | here ]].
[1] https://clang.llvm.org/docs/LanguageExtensions.html#extensions-to-specify-floating-point-flags
Reviewed By: vzakhari, awarzynski
Differential Revision: https://reviews.llvm.org/D136080
Previously an error raised during an expansion of response files (including
configuration files) was ignored and only the fact of its presence was
reported to the user with generic error messages. This made it difficult to
analyze problems. For example, if a configuration file tried to read an
inexistent file, the error message said that 'configuration file cannot
be found', which is wrong and misleading.
This change enhances handling errors in the expansion so that users
could get more informative error messages.
Differential Revision: https://reviews.llvm.org/D136090
Previously the program would crash on this input:
```
#else
#if X
```
The problem was that in `parsePPElse`, `PPBranchLevel` would be
incremented when the first `#else` gets parsed, but `PPLevelBranchCount`
and `PPLevelBranchIndex` would not be updated together.
I found the problem when working on D135740.
Differential Revision: https://reviews.llvm.org/D135972
Previously an error raised during an expansion of response files (including
configuration files) was ignored and only the fact of its presence was
reported to the user with generic error messages. This made it difficult to
analyze problems. For example, if a configuration file tried to read an
inexistent file, the error message said that 'configuration file cannot
be found', which is wrong and misleading.
This change enhances handling errors in the expansion so that users
could get more informative error messages.
Differential Revision: https://reviews.llvm.org/D136090
Print source location info and demangle the name, compared
to the default behavior.
Several observations:
1. Specially handling this seems to give source locations
without enabling debug info, and also gives columns compared
to the backend diagnostic.
2. We're duplicating diagnostic effort in DiagnosticInfo
and clang. This feels wrong, but clang can demangle and I guess
have better debug info available? Should clang really have any of this
code? For the purposes of this diagnostic, the important piece
is just reading the source location out of the llvm::Function.
3. lld is not duplicating the same effort as clang with LTO, and
just directly printing the DiagnosticInfo as-is. e.g.
$ clang -fgpu-rdc
lld: error: local memory (480000) exceeds limit (65536) in function '_Z12use_huge_ldsIiEvv'
lld: error: local memory (960000) exceeds limit (65536) in function '_Z12use_huge_ldsIdEvv'
$ clang -fno-gpu-rdc
backend-resource-limit-diagnostics.hip:8:17: error: local memory (480000) exceeds limit (65536) in 'void use_huge_lds<int>()'
__global__ void use_huge_lds() {
^
backend-resource-limit-diagnostics.hip:8:17: error: local memory (960000) exceeds limit (65536) in 'void use_huge_lds<double>()'
2 errors generated when compiling for gfx90a.
4. Backend errors are not observed with -save-temps and -fno-gpu-rdc or -flto,
and the compile incorrectly succeeds.
5. The backend version prints error: <location info>; clang prints <location info>: error:
6. -emit-codegen-only is totally broken for AMDGPU. MC
gets a null target streamer. I do not understand why this
is a thing. This just creates a horrible edge case.
Just work around this by emitting actual code instead of blocking
this patch.
rC220726 had a bug: `echo "<cstdlib>" | clang -M -MP -x c++ - 2>/dev/null`
(used by glibc/configure.ac find_cxx_header) omitted a `cstdlib:` line. Instead
of filtering out `<stdin>` in `Dependencies`, retain it (so that the number of
entries does not change whether or not main file is `<stdin>`) and filter the
`PhonyTarget` output.
Avoid calling getenv in the MC layer and let the clang driver do it so
that it is reflected in the command-line as an -mllvm option.
rdar://101558354
Differential Revision: https://reviews.llvm.org/D136888
concept
When we failed the lookup of the function, we tried to form a
RecoveryExpr that caused us to recursively re-check the same constraint,
which caused us to try to double-insert the satisfaction into the cache.
This patch makes us just return the inner-cached version instead. We DO
end up double-evaluating thanks to the recovery-expr, but there isn't a
good way around that.
visit (lowercase V) sets DiscardValue to false and calls Visit
(uppercase V). So we can't just call Visit (uppercase V) ourselves,
since then we aren't handling DiscardValue correctly.
This is currently irrelevant but will make a difference later.
Also, the naming isn't my fault and might change later.
Add an option --[no-]offload-add-rpath to control whether to
pass -rpath to linker for HIP runtime library. By default it
is off to match gcc/clang behavior for not adding -rpath
for runtime library by default.
Reviewed by: Artem Belevich
Differential Revision: https://reviews.llvm.org/D136854
Although i32 type is illegal in the backend, RV64I has pretty good support for i32 types by using W instructions.
By adding n32 to the DataLayout string, middle end optimizations will consider i32 to be a native type. One known effect of this is enabling LoopStrengthReduce on loops with i32 induction variables. This can be beneficial because C/C++ code often has loops with i32 induction variables due to the use of `int` or `unsigned int`.
If this patch exposes performance issues, those are better addressed by tuning LSR or other passes.
Reviewed By: asb, frasercrmck
Differential Revision: https://reviews.llvm.org/D116735
Callsite `DISubprogram` entries are not generated for:
- builtin functions;
- external functions with reserved names (e.g. names starting from "__").
This limitation was added by the commit [1] as a workaround for the
situation described in [2] that triggered the IR verifier error.
The goal of the present commit is to lift this limitation by adjusting
the IR verifier logic.
The logic behind [1] is to avoid the following situation:
- a `DISubprogram` is added for some builtin function;
- there is some location where this builtin is also emitted by a
transformation (w/o debug location);
- the `Verifier::visitCallBase` sees a call to a function with
`DISubprogram` but w/o debug location and emits an error.
Here is an updated example of such situation taken from [2]:
```
extern "C" int memcmp(void *, void *, long);
struct a { int b; int c; int d; };
struct e { int f[1000]; };
bool foo(e g, e &h) {
// DISubprogram for memcmp is created here when [1] is commented out
return memcmp(&g, &h, sizeof(e));
}
bool bar(a &g, a &h) {
// memcmp might be generated here by MergeICmps
return g.b == h.b && g.c == h.c && g.d == h.d;
}
```
This triggers the verifier error when:
- compiled for AArch64:
`clang++ -c -g -Oz -target aarch64-unknown-linux-android21 test.cpp`;
- [1] check is commented out.
Instead of forbidding generation of `DISubprogram` entries as in [1]
one can instead adjust the verifier to additionally check if callee
has a body. Functions w/o bodies cannot be inlined and thus verifier
warning is not necessary.
E.g. `llvm::InlineFunction` requires functions for which
`GlobalValue::isDeclaration() == false`.
[1] 568db780bb
[2] https://bugs.chromium.org/p/chromium/issues/detail?id=1022296
Differential Revision: https://reviews.llvm.org/D136041
They get allocated when calling initialize() on a primitive array. And
they get free'd when the array is fully initialized. However, when that
never happens, they get leaked. Fix that by calling the destructor of
global variables.
Differential Revision: https://reviews.llvm.org/D136826
When assigning to them, we can't classify the expression type, because
that doesn't contain the right information.
And when reading from them, we need to do the extra deref, just like we
do when reading from a DeclRefExpr.
Differential Revision: https://reviews.llvm.org/D136012
gonglingqin