Similar for RISCV::parseTuneCPU and RISCV::checkTuneCPUKind.
This makes the CPUKind enum no longer part of the API. It wasn't
providing much value. It was only used to pass between the two
functions.
By removing it, we can remove a dependency on a tablegen generated
file from the RISCVTargetParser.h file. Then we can remove a
dependency from several CMakeLists.txt.
Clang was writing paths to the dependency file that don't exist when using a sysroot with symlinks, causing everything to get rebuilt every time. This is reproducible on Linux by creating a symlink to '/', using that as the sysroot, and trying to build something with ninja that includes the C++ stdlib (e.g. a typical build of LLVM).
This fixes https://github.com/ninja-build/ninja/issues/1330 and somewhat matches gcc.
gcc canonicalizes system headers in dependency files under a -f[no-]canonical-system-headers, but it makes more sense to look at -canonical-prefixes.
D37954 was a previous attempt at this.
Fixed use of %T instead of %t in test, causing bots to fail the test on the initial commit.
Reviewed By: hans
Differential Revision: https://reviews.llvm.org/D149187
Rather than having a separate pass to add the hint instructions,
emit them directly into the streamer during asm printing.
Reviewed By: BeMg, kito-cheng
Differential Revision: https://reviews.llvm.org/D149511
When cuchar is compiled independently on platforms that don't have <uchar.h>, it doesn't get a declaration of mbstate_t, and so makes an empty declaration for ::mbstate_t. That conflicts with the declarations in __mbstate_t.h and cwchar since both of those headers do get mbstate_t before making ::mbstate_t.
Change `__mbstate_t.h` to just get the underlying declaration for mbstate_t and not make a declaration for ::mbstate_t. Include __mbstate_t.h in uchar.h and wchar.h when their next headers aren't available so that at least mbstate_t gets defined.
Add __std_mbstate_t.h to declare ::mbstate_t for headers that need that when cuchar or cwchar aren't available (because either _LIBCPP_HAS_NO_WIDE_CHARACTERS or _LIBCPP_CXX03_LANG).
Reviewed By: ldionne, Mordante, #libc, philnik
Differential Revision: https://reviews.llvm.org/D148542
This commutes the extension (`arith.extsi`, `arith.extui`) over the
following vector ops: `vector.broadcast`, `vector.shape_cast`,
`vector.transpose`, `vector.flat_transpose`.
I focused on these as I saw them getting created by vector unroll
patterns. Maybe except `vector.flat_transpose`.
Reviewed By: antiagainst
Differential Revision: https://reviews.llvm.org/D149534
Allow to commute extension ops over `vector.insertelement` and
`vector.insert_strided_slice`.
Reviewed By: antiagainst
Differential Revision: https://reviews.llvm.org/D149509
Appears to be causing out-of-tree test failures. Reverting while the
issue is investigated.
This reverts commit fbc7fcf5ae26fad7db3e7c861fc6447e02b39cf0.
This is purely so that we can expose and work through downstream codegen issues. My intention is to see if we can get this disabled by default, but that requires fixing a bunch of downstream issues first.
Clang was writing paths to the dependency file that don't exist when using a sysroot with symlinks, causing everything to get rebuilt every time. This is reproducible on Linux by creating a symlink to '/', using that as the sysroot, and trying to build something with ninja that includes the C++ stdlib (e.g. a typical build of LLVM).
This fixes https://github.com/ninja-build/ninja/issues/1330 and somewhat matches gcc.
gcc canonicalizes system headers in dependency files under a -f[no-]canonical-system-headers, but it makes more sense to look at -canonical-prefixes.
D37954 was a previous attempt at this.
Reviewed By: hans
Differential Revision: https://reviews.llvm.org/D149187
Add a new wraper type that represents either of `ExtSIOp` or `ExtUIOp`.
This is to simplify the code by using a single type, so that we do not
have to use templates or branching to handle both extension kinds.
Reviewed By: antiagainst
Differential Revision: https://reviews.llvm.org/D149485
The previous code structure and comments were exceedingly confusing. I have multiple times looked at this code and suspected a bug. This time, I decided to take the time to reflow the code and comment out why it is correct.
The only suspect (to me) case left is that an underaligned access with a unit stride (in terms of the access type) might miss the undefined null pointer when wrapping. This is unlikely to be an issue for C/C++ code with real page sizes, so I'm not bothering to fully convince myself whether that case is correct or not.
Before this patch, initialized class members would have the LifetimeKind
LK_MemInitializer, which does not allow for binding a temporary to a
reference. Binding to a temporary however is allowed in parenthesized
aggregate initialization, even if it leads to a dangling reference. To
fix this, we create a new EntityKind, EK_ParenAggInitMember, which has
LifetimeKind LK_FullExpression.
This patch does *not* attempt to diagnose dangling references as a
result of using this feature.
This patch also refactors TryOrBuildParenListInitialization(...) to
accomodate creating different InitializedEntity objects.
Fixes#61567
[0]: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0960r3.html
Reviewed By: shafik
Differential Revision: https://reviews.llvm.org/D148274
We have to unbox the boxchar variables in order to get to
the raw address that can be used for emboxing.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D149473
We have to keep it as a box, since taking box_addr of the optional
box may be invalid.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D149505
This patch reverts rGae739aefd7473517d3f08b5c8d08a66c7f469198 to address performance regressions reported by our [CI](https://github.com/dtcxzyw/llvm-ci/issues/137) after rG2ec1d0f427c7822540352c0c14d057e7bfe4f77b.
For example:
```
define ptr @const_gep_chain(ptr %p, i64 %a) {
%p1 = getelementptr inbounds i8, ptr %p, i64 %a
%p2 = getelementptr inbounds i8, ptr %p1, i64 1
%p3 = getelementptr inbounds i8, ptr %p2, i64 2
%p4 = getelementptr inbounds i8, ptr %p3, i64 3
ret ptr %p4
}
```
The last three GEPs will not be folded since rG2ec1d0f427c7822540352c0c14d057e7bfe4f77b.
I think it is appropriate to remove this code because there is no compile-time regression reported in our benchmarks.
Reviewed By: nikic
Differential Revision: https://reviews.llvm.org/D149240
Previously, when checking whether an in-class initializer exists when
performing parenthesized aggregate initialization, Clang checks that the
output of FieldDecl::getInClassInitializer() is non-null. This is
incorrect; if the field is part of a templated type, then
getInClassInitializer() will return nullptr if we haven't called
Sem::BuildCXXDefaultInitExpr(...) before, even if
FieldDecl::hasInClassInitializer() returns true. The end result is that
Clang incorrectly ignores the in class initializer and
value-initializes the field. The fix therefore is to instead call
FieldDecl::hasInClassInitializer(), which is what we do for braced init
lists [0].
Before this patch, Clang does correctly recognize the in-class field
initializer in certain cases. This is Sema::BuildCXXDefaultInitExpr(...)
populates the in class initializer of the corresponding FieldDecl
object. Therefore, if that method was previously called with the same
FieldDecl object, as can happen with a decltype(...) or a braced list
initialization, FieldDecl::getInClassInitializer() will return a
non-null expression, and the field becomes properly initialized.
Fixes 62266
[0]: be5f35e24f/clang/lib/Sema/SemaInit.cpp (L685)
Reviewed By: shafik
Differential Revision: https://reviews.llvm.org/D149389
Fix a bug where after
github.com/llvm/llvm-project/commit/68dd51421f16f1e17cd453cb1730fcca99a6cfb7
refactor where we are not passing -mabi=vec-extabi to th backend.
This was briefly mentioned as a possibility in review discussion on D149369.
One slightly surprising bit to call out - these interfaces can get invoked with non-vector typed arguments. LoopVectorizer likes to call the costing interfaces with scalar types when unrolling, but not vectorizing. I found that surprising, not sure if others do.
Differential Revision: https://reviews.llvm.org/D149462
`BytecodeWriter.h` is now included in `IR.h`, and the corresponding dependency should be moved to `header_deps`. This change fixes Google's internal build, which seems to have a stricter layering check than bazel's, but it's still the right thing to do.
Differential Revision: https://reviews.llvm.org/D149576
This revision updates the description of
`__sanitizer_annotate_contiguous_container` in includes. Possibilites of
the function were changed in D132522 and it supports:
- unaligned beginning,
- shared first/last granule with other objects.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D149341
Can't return a well-formed IR output while enabling version to be bumped
up during emission. Previously it would return min version but
potentially invalid IR which was confusing, instead make it return
error and abort immediately instead.
Differential Revision: https://reviews.llvm.org/D149569
The linker flag `--version-script` may not be supported by all linkers, such as
macOS's linker. `libomp` is already capable of detecting whether the linker supports
it and append the linker flag accordingly. Since currently we assume `libomptarget`
only works on Linux, we don't do the check accordingly. This patch simply adds
the check before adding it to linker flag. This will be the first patch to make
OpenMP target offloading work on macOS. Note that CMake files in `plugins` are
not touched before they are going to be removed pretty soon anyway.
Reviewed By: jhuber6
Differential Revision: https://reviews.llvm.org/D149555
The documentation is still rather terse because it needs to fit
onto a single line of clang --help output.
But at least it lists what the user can specify and documents the
non-obvious syntax.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D149456
This is folloup to b5595836, which missed the
Replacemen variable.
Before b5595836 the code assumed that alloca
ptrs are not tagged so tagging is implemented
as simple OR.
So this patch completes support of tagged SP
by passing untagged alloca pointers into
tagPointer.
