Renames StartAddress and EndAddress members to Start and End.
Adds contains and overlap methods.
Adds a constructor from an address and size.
These changes are counterparts to LLVM commits ef391df2b6, c0d889995e, and
37f1b7a3f3.
This reverts commit bef55a2b47 while I investigate
failures on some bots. Also reverts "[lli] Add ChildTarget dependence on
OrcTargetProcess library." (7a219d801b) which was
a fallow-up to bef55a2b47.
EPCGenericRTDyldMemoryMnaager is an EPC-based implementation of the
RuntimeDyld::MemoryManager interface. It enables remote-JITing via EPC (backed
by a SimpleExecutorMemoryManager instance on the executor side) for RuntimeDyld
clients.
The lli and lli-child-target tools are updated to use SimpleRemoteEPC and
SimpleRemoteEPCServer (rather than OrcRemoteTargetClient/Server), and
EPCGenericRTDyldMemoryManager for MCJIT tests.
By enabling remote-JITing for MCJIT and RuntimeDyld-based ORC clients,
EPCGenericRTDyldMemoryManager allows us to deprecate older remote-JITing
support, including OrcTargetClient/Server, OrcRPCExecutorProcessControl, and the
Orc RPC system itself. These will be removed in future patches.
One of the cases identified in PR45116 - we don't need to limit store narrowing to ABI alignment, we can use allowsMemoryAccess - which tests using getABITypeAlign, but also checks if a target permits (fast) misaligned memory access by checking allowsMisalignedMemoryAccesses as a fallback.
Earlier during the development of {D69764} I felt it was no longer necessary to
ensure we were not trying to change code which didn't need to change
and we felt this could be removed, however I'd like to bring this back for now
as I am seeing some false positives in terms of the "replacements"
What I see is the generation of a replacement which is a "No Op" on the original
code, I think this comes about because of the merging of replacements:
```
static const a;
->
const static a;
->
static const a;
```
The replacements don't really merge, in such a way as to identify when we have gone
back to the original
Also remove the Penalty as I'm not using it (and it became marked as set and no used,
I'd rather get rid of it if it means nothing)
I think we need to do this step for now, as many people use the --output-replacements-xml
to identify that the file "needs a clang-format"
The same can be seen with the -n or --dry-run option as this uses the replacements
to drive the error/warning output.
Reviewed By: HazardyKnusperkeks
Differential Revision: https://reviews.llvm.org/D110392
Update the costs to match the codegen from combineMulToPMADDWD - not only can we use PMADDWD is its zero-extended, but also if its a constant or sign-extended from a vXi16 (which can be replaced with a zero-extension).
If we are multiplying by a sign-extended vXi32 constant, then we can mask off the upper 16 bits to allow folding to PMADDWD and make use of its implicit sign-extension from i16
We already do this on SSE41 targets where we have sext/zext instructions, now that combineShiftToPMULH handles SSE2 targets, we can enable this here as well.
With improved shuffle combines (in particular canonicalizeShuffleWithBinOps), we can now usefully perform this on any SSE2+ target.
We should be able to remove this entirely and just use DAGCombiner's combineShiftToMULH if we can someday get it to support illegal (pre-widened) types.
Replace misc. StringConvert uses with llvm::to_integer()
and llvm::to_float(), except for cases where further refactoring is
planned. The purpose of this change is to eliminate the StringConvert
API that is duplicate to LLVM, and less correct in behavior at the same
time.
Differential Revision: https://reviews.llvm.org/D110447
This patch is part of the upstreaming effort from fir-dev branch.
Add a description for the fir.array_load opeartion and rename lenParams to typeparams.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D110393
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Linking against the LibXml2::LibXml2 target has the advantage of not only importing the library, but also adding the include path as well as any definitions the library requires. In case of a static build of libxml2, eg. a define is set on Windows to remove any DLL imports and export.
LLVM already makes use of the target, but c-index-test and lldb were still linking against the library only.
The workaround for Mac OS-X that I removed seems to have also been made redundant since https://reviews.llvm.org/D84563 I believe
Differential Revision: https://reviews.llvm.org/D109975
This patch adds functionality to FlatAffineConstraints to remove local
variables using equalities. This helps in keeping output representation of
FlatAffineConstraints smaller.
This patch is part of a series of patches aimed at generalizing affine
dependence analysis.
Reviewed By: bondhugula
Differential Revision: https://reviews.llvm.org/D110056
Given:
- A jump table
- Which jumps to the next block
- The next block ends in a WLS
- Where the WLS conditionally jumps to block earlier in the program.
The Arm block placement pass would attempt to move the block containing
the WLS earlier, as the WLS instruction can only branch forward. In
doing so it would add a branch from the jumptable block to the WLS
block, thinking it previously fell-through.
This in itself would be fine, if a little inefficient, but the constant
island pass expects all instructions after a jump-table branch to have
been removed by analyzeBranch. So it gets confused and can assign the
same labels to multiple jump table blocks.
I've changed the condition to the same as used in analyzeBranch.
It's only used during race reporting.
There is no point in polluting the main header file with it.
Reviewed By: xgupta
Differential Revision: https://reviews.llvm.org/D110470
See PR51872 for the original repro.
This fixes a crash when converting a templated constructor into a deduction
guide, in case any of the template parameters were invalid.
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Reviewed By: rsmith
Differential Revision: https://reviews.llvm.org/D110460
We currently, incorrectly, assume that a range always has at least
one element when building a contiguous range. This commit adds
a proper empty check to avoid crashing.
Differential Revision: https://reviews.llvm.org/D110457
This reverts commit 03142c5f67.
Breaks check-asan if system ld doesn't support --push-state, even
if lld was built and is used according to lit's output.
See comments on https://reviews.llvm.org/D110128
This change adds the ability to create source tarballs for unreleased or untagged code by providing the `--git-ref <GIT_REF>` flag to the `llvm/utils/release/export.sh` script. This is useful for creating daily snapshot tarballs that can easily be consumed by packagers who want to build a daily snapshot.
The default behavior of `export.sh` hasn't changed.
You may also provide a `--template` argument to say how the artifacts
are supposed to be named (as suggested by @hans).
The `-help` output of `export.sh` was changed quite significantly to look like this:
```
Export the Git sources and build tarballs from them.
Usage: export.sh [-release|--release <major>.<minor>.<patch>]
[-rc|--rc <num>]
[-final|--final]
[-git-ref|--git-ref <git-ref>]
[-template|--template <template>]
Flags:
-release | --release <major>.<minor>.<patch> The version number of the release
-rc | --rc <num> The release candidate number
-final | --final When provided, this option will disable the rc flag
-git-ref | --git-ref <git-ref> (optional) Use <git-ref> to determine the release and don't export the test-suite files
-template | --template <template> (optional) Possible placeholders: $PROJECT $YYYYMMDD $GIT_REF $RELEASE $RC.
Defaults to '${PROJECT}-${RELEASE}${RC}.src.tar.xz'.
The following list shows the filenames (with <placeholders>) for the artifacts
that are being generated (given that you don't touch --template).
* llvm-<RELEASE><RC>.src.tar.xz
* clang-<RELEASE><RC>.src.tar.xz
* compiler-rt-<RELEASE><RC>.src.tar.xz
* libcxx-<RELEASE><RC>.src.tar.xz
* libcxxabi-<RELEASE><RC>.src.tar.xz
* libclc-<RELEASE><RC>.src.tar.xz
* clang-tools-extra-<RELEASE><RC>.src.tar.xz
* polly-<RELEASE><RC>.src.tar.xz
* lldb-<RELEASE><RC>.src.tar.xz
* lld-<RELEASE><RC>.src.tar.xz
* openmp-<RELEASE><RC>.src.tar.xz
* libunwind-<RELEASE><RC>.src.tar.xz
* flang-<RELEASE><RC>.src.tar.xz
Additional files being generated:
* llvm-project-<RELEASE><RC>.src.tar.xz (the complete LLVM source project)
* test-suite-<RELEASE><RC>.src.tar.xz (only when not using --git-ref)
To ease the creation of snapshot builds, we also provide these files
* llvm-release-<YYYYMMDD>.txt (contains the <RELEASE> as a text)
* llvm-rc-<YYYYMMDD>.txt (contains the rc version passed to the invocation of export.sh)
* llvm-git-revision-<YYYYMMDD>.txt (contains the current git revision sha1)
Example values for the placeholders:
* <RELEASE> -> 13.0.0
* <YYYYMMDD> -> 20210414
* <RC> -> rc4 (will be empty when using --git-ref)
In order to generate snapshots of the upstream main branch you could do this for example:
export.sh --git-ref upstream/main --template '${PROJECT}-${YYYYMMDD}.src.tar.xz'
```
Reviewed By: tstellar
Differential Revision: https://reviews.llvm.org/D101446
When using the system debugserver for testing, copy the binary in the
LLDB.framework Resource directory instead of the build's bin directory.
rdar://82998263
Clang will encode names that should be able to be simplified as
"_STNname|<template, args>" (eg: "_STNt1|<int>") - this verification
mode will detect these names, decode them, create the original name
("t1<int>") and the simple name ("t1") - letting the simple name run
through the usual rebuilding logic - then compare the two sources of the
full name - the rebuilt and the _STN encoding.
This helps ensure that -gsimple-template-names is lossless.
When determining the incompleteness of a DIE based on its children, make
sure we propagate it across union types. See test case for an example.
Without this patch we never emit the definition of Container_ivars.
Differential revision: https://reviews.llvm.org/D110443
In order to be consistent with compiler that interprets zero count as unexecuted(cold), this change reports zero-value count for unexecuted part of function code. For the implementation, it leverages the range counter, initializes all the executed function range with the zero-value. After all ranges are merged and converted into disjoint ranges, the remaining zero count will indicates the unexecuted(cold) part of the function.
This change also extends the current `findDisjointRanges` method which now can support adding zero-value range.
Reviewed By: hoy, wenlei
Differential Revision: https://reviews.llvm.org/D109713
For such cases, the type of the constant DenseElementsAttr is
different from the transpose op return type.
Reviewed By: rsuderman
Differential Revision: https://reviews.llvm.org/D110446
This patch introduces non-CS AutoFDO profile generation into LLVM. The profile is supposed to be well consumed by compiler using `-fprofile-sample-use=[profile]`.
After range and branch counters are extracted from the LBR sample, here we go through each addresses for symbolization, create FunctionSamples and populate its sub fields like TotalSamples, BodySamples and HeadSamples etc. For inlined code, as we need to map back to original code, so we always add body samples to the leaf frame's function sample.
Reviewed By: wenlei, hoy
Differential Revision: https://reviews.llvm.org/D109551
This patch introduces a generic reduction detection utility that works
across different dialecs. It is mostly a generalization of the reduction
detection algorithm in Affine. The reduction detection logic in Affine,
Linalg and SCFToOpenMP have been replaced with this new generic utility.
The utility takes some basic components of the potential reduction and
returns: 1) the reduced value, and 2) a list with the combiner operations.
The logic to match reductions involving multiple combiner operations disabled
until we can properly test it.
Reviewed By: ftynse, bondhugula, nicolasvasilache, pifon2a
Differential Revision: https://reviews.llvm.org/D110303
Similar to https://reviews.llvm.org/D109637, there is a whole invalid line of message in perfscript.
```
warning: Invalid address in LBR record at line 14118674: Processed 14138923 events and lost 1 chunks!
warning: Invalid address in LBR record at line 14118676: Check IO/CPU overload!
```
This only happened for LBR only perfscript, hybridperfscript have a check of " 0x" to make sure it's the LBR perf line.
Reviewed By: hoy, wenlei
Differential Revision: https://reviews.llvm.org/D110424
Non-entry functions have 32 caller saved VGPRs available. If we
promote alloca to consume more registers we will have to spill
CSRs. There is no reason to eliminate scratch access to get
another scratch access instead.
Differential Revision: https://reviews.llvm.org/D110372
Lang Hames