This captures the target shader model and pipeline stage into the DXIL
metadata for consumption by the DirectX runtime.
Reviewed By: python3kgae
Differential Revision: https://reviews.llvm.org/D134469
This is a refactor for another patch. For now we move the vreg
creation to the caller.
Reviewed By: frasercrmck
Differential Revision: https://reviews.llvm.org/D135008
RenderAsInput is for -Wa,/-Wl, style options which forward their values
as used by llvm::opt::Arg::renderAsInput. These short options don't use RenderAsInput.
Recent improvements to the code structure mean we don't need to reset
the condition's predicate in the IR and later restore it. Remove the
restorer logic.
This adds a combine that handles
```
(x + y) - y -> x
(x + y) - x -> y
x - (y + x) -> 0 - y
x - (x + z) -> 0 - z
```
On AArch64, we get added benefit for `0 - y` because it can be selected to a
`neg` instruction.
Differential Revision: https://reviews.llvm.org/D135010
When using llvm-libtool-darwin as a drop in replacement for cctools
libtool, Xcode expects you to create a dependency info file. This file
is a very simple format describing the input files, the output files,
and the version of the tool. This logic is mirrored from that of
ld64.lld, which supports creating this file as well. Ideally we could
extract it, but I don't think we want to throw this into one of the
grab-bag libraries given how small the logic is.
Differential Revision: https://reviews.llvm.org/D134322
cctools libtool allows you to link dynamic libraries by passing through
a number of arguments to ld64. Because of this the default arguments
libtool receives in Xcode contains arguments that only matter in that
case. This change ignores this argument, at least until we ever support
that dynamic use case, so that you can use llvm-libtool-darwin as a
drop-in replacement in Xcode for cctools libtool. There are more
arguments we could ignore for this case, but we can probably add those
as the use case comes up.
Differential Revision: https://reviews.llvm.org/D134309
Move ReadPacketWithOutputSupport() from GDBRemoteCommunication
to GDBRemoteClientBase. This function is client-specific and moving
it there simplifies followup patches that split communication into
separate thread.
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.llvm.org/D135028
Currently, AArch64 doesn't support vectorization for non temporal loads because `isLegalNTLoad` is not implemented for the target.
This patch applies similar functionality as `D73158` but for non temporal loads
Reviewed By: fhahn
Differential Revision: https://reviews.llvm.org/D131964
Currently all of the flags beginning with `--offload` such as
`--offload-arch` or `--offload-device-only` require the double-dash
form. However, if a user uses a single dash it will instead name a file
'ffload-arch' for example. This has been the cause of a lot of user
confusion. This patch changes these options to also accept a single
dash. This is similar to many other driver arguments beginning with
`-o`.
Reviewed By: JonChesterfield
Differential Revision: https://reviews.llvm.org/D135076
llvm/lib/Transforms/Utils/CodeLayout.cpp uses std::abs() with double argument,
which is provided by cmath header, which is not explicitly included into CodeLayout.cpp.
The implicit include in llvm/include/llvm/Support/MathExtras.h was removed in
commit 16544cbe64
Inserting explicit include of cmath into CodeLayout.cpp in order to fix build on MacOS.
Committed on behalf of alsemenov (Aleksei Semenov)
Reviewed By: thieta
Differential Revision: https://reviews.llvm.org/D135072
The constant is already commuted for an fmul opcode,
but this code can be called more directly for fma,
so we have to swap for that caller. There are tests
in InstSimplify and InstCombine to verify that this
works as expected.
The stderr to stdout piping results in the two streams being interleaved on Windows.
Write stderr to a temp-file instead and run separate FileCheck on it.
D132236 would have introduced regressions in the symbol lifetime
handling. However, the testsuite did not catch this, so here we have
some tests, which would have break if D132236 had landed.
This patch addresses the comment https://reviews.llvm.org/D132236#3753238
Co-authored-by: Balazs Benics <balazs.benics@sonarsource.com>
Reviewed By: martong
Differential Revision: https://reviews.llvm.org/D134941
The modifier bits in the schedule type is not used/supported in the
static scheduler, so it should be ignored.
Differential Revision: https://reviews.llvm.org/D134983
Makes things look more similar to the ELF port, and removes some
slightly deep nesting.
No behavior change.
Differential Revision: https://reviews.llvm.org/D135032
The code introduced in https://reviews.llvm.org/D130881 has a bug as it may cause a use-after-free error that can be caught by ASAN.
The bug essentially boils down to iterator invalidation of `DenseMap`. The expression `SDEI[To] = I->second;` may cause `SDEI` to grow if `To` is inserted for the very first time. When that happens, all existing iterators to the map are invalidated as their backing storage has been freed. Accessing `I->second` is then invalid and attempts to access freed memory (as `I` is an iterator of `SDEI`).
This patch fixes that quite simply by first making a copy of `I->second`, and then moving into the possibly newly inserted KV of the ` DenseMap`.
No test attached as I am not sure it is practible to test.
Differential revision: https://reviews.llvm.org/D135019
It casued some runtimes builds to fail with cmake error
No target "libcxx-abi-static"
see code review.
> When in-tree libcxx is selected as the sanitizer C++ ABI, use
> libcxx-abi-* targets rather than libcxxabi and libunwind directly.
>
> Differential Revision: https://reviews.llvm.org/D134855
This reverts commit 414f9b7d2f.
Round-tripping pointers via size_t is not portable, the C/C++ standards
only require this to be valid when using (u)intptr_t.
Originally committed to the CHERI fork of LLVM as
dd01245185,
but I forgot to upstream the change. I rediscovered this issue due to a
compiler warning when building libc++ on a Arm Morello system.
Reviewed By: #libc, ldionne, philnik
Differential Revision: https://reviews.llvm.org/D134363
The revision enriches the debug locations generated during LLVMIR to MLIR translation with file name information and adds a separate test to exercise the debug location translation.
Reviewed By: ftynse
Differential Revision: https://reviews.llvm.org/D135069
As described in Issue #57642, `flang` currently lacks SPARC support in
`Optimizer/CodeGen/Target.cpp`, which causes a considerable number of tests
to `FAIL` with
error: flang/lib/Optimizer/CodeGen/Target.cpp:310: not yet implemented:
target not implemented
This patch fixes this by following GCC`s documentation of the ABI described
in the Issue.
Tested on `sparcv9-sun-solaris2.11`.
Differential Revision: https://reviews.llvm.org/D133561
Includes handling of constants with vector type in isKnownNeverNaN.
For AMDGPU results in not making fcanonicalize during legalization
for vector inputs to fmaxnum_ieee and fminnum_ieee. Does not affect
end result since there is a combine that eliminates fcanonicalize.
Differential Revision: https://reviews.llvm.org/D88573
Added a helper in TargetLibraryInfo to get size of "size_t" in bits,
given a Module reference. The new getSizeTSize helper is using the
same strategy as for example isValidProtoForLibFunc has been using
in the past, assuming that the size can be derived by asking
DataLayout about the size/type of a pointer to int.
FortifiedLibCallSimplifier::optimizeStrpCpyChk was changed to use
the new getSizeTSize helper instead of assuming that sizeof(size_t)
is equal to sizeof(int*) by itself (that is the assumption used in
TargetLibraryInfoImpl::getSizeTSize so the result will be the same).
Having a common helper for this ensure that we use the same strategy
when deriving the size of "size_t" in different parts of the code.
One bonus with this refactoring (basing it on Module instead of just
DataLayout) is that it makes it easier to override this for a specific
target triple, in case the assumption of using getPointerSizeInBits
wouldn't hold.
Differential Revision: https://reviews.llvm.org/D110585
The only current options to create a supervectorization pass from an
external dialect is to use `createSuperVectorizePass` with the virtual
vector dimensions as a parameter, but the pass accepts other parameters.
This patch enables external users to create a supervectorizer pass
exposing all available option.
Differential Revision: https://reviews.llvm.org/D134632
For TRIM and REPEAT calls, semantics was creating ProcedureDesignators
using the length parameter of the arguments. This caused bugs when
folding LEN(TRIM(char_explicit_constant_length)). The same did not
appeared in folding for REPEAT because it is rewritten at a higher
level to LEN(c)*N.
This is not only a folding issue since any place (like lowering) may
try to use the bad length parameter from the created ProcedureDesignator.
Update intrinsic resolution to not copy the length parameter for TRIM
and REPEAT.
Differential Revision: https://reviews.llvm.org/D134970
Delay-loaded imports creats a load thunk with a symbol name. Before this
change, the name uses a `__imp_load_` prefix. On the other hand, normal
import uses the `__imp_` prefix for the import address pointer. If an
import symbol named `load_func` is imported normally and another named
`func` is imported using delay-load, this can cause a symbol name
collision.
This patch changes delay-load imports to use `__imp___load_` prefix.
Because it is less likely for normal imports to have a name starting in
`__load_` this should reduce the chance of a name collision.
Reviewed By: mstorsjo
Differential Revision: https://reviews.llvm.org/D134464
Before this, LLD sets OrdinalBase to 0, which deviates from usual
practices. This technically would allow LLD to export a symbol using
ordinal 0, however LLD never use export ordinal 0, which results in
binaries with export tables always having an empty export at ordinal 0.
This change makes LLD set OrdinalBase to 1 and not create the empty
export with ordinal 0, which makes its behaviour more in line with both
the MSVC linker and the GNU linker.
Reviewed By: mstorsjo
Differential Revision: https://reviews.llvm.org/D134140
Chris Bieneman