https://commondatastorage.googleapis.com/chromium-browser-clang/llvm-include-analysis.html
Excessive use of the <string> header has a massive impact on compile time; its most commonly included via the ErrorHandling.h header, which has to be included in many key headers, impacting many source files that have no need for std::string.
As an initial step toward removing the <string> include from ErrorHandling.h, this patch proposes to update the fatal_error_handler_t handler to just take a raw const char* instead.
The next step will be to remove the report_fatal_error std::string variant, which will involve a lot of cleanup and better use of Twine/StringRef.
Differential Revision: https://reviews.llvm.org/D111049
The commit e497b12a69 went and regenerated
all the checks lines in the Arm speculation-hardening-sls.ll test in a
way that removed most of the important checks. This just resets them
back to how they were before, with the single character fix to change:
; NOHARDENARM: {{bxge lr$}}
to
; NOHARDENARM: {{bxgt lr$}}
Differential Revision: https://reviews.llvm.org/D111074
This option is needed for passes that are known to reach a fix point, but may
need many iterations depending on the size of the input IR.
Differential Revision: https://reviews.llvm.org/D111058
As suggested in D110830, this copies the Arm backend method of testing
function calls through specific registers, using inline assembly to
force the variable into x16 to check that the __llvm_slsblr_thunk calls
do not use a register that may be clobbered by the linker.
Differential Revision: https://reviews.llvm.org/D111056
Partition libFIROptimizer into smaller libraries that reflect the
structure. Adapt potential problems.
This patch is part of the upstreaming effort from fir-dev branch. It's a
building stone to upstreaming transformations.
Reviewed By: schweitz
Differential Revision: https://reviews.llvm.org/D111055
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
This commit has introduced test failures in internal google tests.
Working theory is they are caused by a genuine problem in the patch
which gets tripped by some debug info from system libraries.
Reverting while we try to reproduce the problem in a self-contained
fashion.
This reverts commit 601168e420.
This change allows better interop with external clients of comprehensive bufferization functions
but is otherwise NFC for the MLIR pass itself.
Differential Revision: https://reviews.llvm.org/D111121
This was missed in ec574f5da4. TIME_UTC
is a define that goes along with timespec_get. The testcase that it is
moved to is only run for >= C++17, so the surrounding ifdef guard
can be dropped.
Differential Revision: https://reviews.llvm.org/D110988
e9ee517930 added support for using
winpthreads on Windows, enabled if `__WINPTHREADS_VERSION` was
defined (i.e. if winpthreads headers have been included before
including libcxx `__config`). This was fragile (libcxx changed
behaviour depending on what headers had been included externally
before), and was changed in a1bc823a59
to use pthreads on Windows whenever the pthread.h header was
available.
This is also fragile; pthread.h might be unavailable while building
libcxx but installed later, and available when users include the
libcxx headers.
In practice, in every modern setup for building libcxx for Windows
I've seen, users end up manually configuring it with
`LIBCXX_HAS_WIN32_THREAD_API=ON`, as the users may have winpthreads
installed (for other libraries/projects to use) while wanting to
build libcxx with the default win32 threading.
Don't automatically pick up pthreads on Windows even if the header
is available. Instead require the user to configure the libcxx
build with `LIBCXX_HAS_PTHREAD_API=ON` if that's desired.
Differential Revision: https://reviews.llvm.org/D110975
Partition libFIROptimizer into smaller libraries that reflect the
structure. Adapt potential problems.
This patch is part of the upstreaming effort from fir-dev branch. It's a
building stone to upstreaming transformations.
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Reviewed By: schweitz
Differential Revision: https://reviews.llvm.org/D111055
Enable verification of live intervals immediately after computing them
(when -early-live-intervals is used) and fix a problem that that
provokes: currently the verifier insists that a segment that ends at an
early-clobber slot must be followed by another segment starting at the
same slot. But before TwoAddressInstruction runs, the equivalent
condition is: a segment that ends at an early-clobber slot must have its
last use tied to an early-clobber def. That condition is harder to check
here, so for now just disable this check until tied operands have been
rewritten.
Differential Revision: https://reviews.llvm.org/D111065
.. and reduce the scope of others. They don't follow llvm coding
standards (which say they should be used only when the same effect
cannot be achieved with the static keyword), and they set a bad example.
PT_LOAD segments in the program header must be sorted by their virtual
addresses, so they should be defined in a similar order as the
associated sections.
Differential Revision: https://reviews.llvm.org/D111068
This is a port of the feature that allows the StackProtector pass to omit
checking code for stack canary checks, and rely on SelectionDAG to do it at a
later stage. The reasoning behind this seems to be to prevent the IR checking
instructions from hindering tail-call optimizations during codegen.
Here we allow GlobalISel to also use that scheme. Doing so requires that we
do some analysis using some factored-out code to determine where to generate
code for the epilogs.
Not every case is handled in this patch since we don't have support for all
targets that exercise different stack protector schemes.
Differential Revision: https://reviews.llvm.org/D98200
This change adds duplication factor multiplier while accumulating body samples for line-number based profile. The body sample count will be `duplication-factor * count`. Base discriminator and duplication factor is decoded from the raw discriminator, this requires some refactor works.
Differential Revision: https://reviews.llvm.org/D109934
This reverts commit d95cd81141.
The selector sometimes leaves unreachable blocks unselected because it uses a
postorder traversal for the block ordering.
With the trap intrinsics now being emitted, these blocks are no longer empty and
the unselected G_INTRINSIC instructions survive past selection. To fix this,
keep track of which blocks are selected and later delete any blocks that weren't
selected.
This simplifies the code in a number of ways and avoids
having to track functions and their types separately.
Differential Revision: https://reviews.llvm.org/D111104
Blank input fields must be interpreted as zero, including the case of
virutal space characters generated from record padding at the end of
an input record. This stopped working sometime in the past few months
for real input (not sure when); here's a fix.
This bug was breaking FCVS test fm111.
Differential Revision: https://reviews.llvm.org/D110765
This is to simplify an upcoming change where we distinguish between
flavors of libc++ by adding an apple-libc++ Lit feature.
Differential Revision: https://reviews.llvm.org/D110870
This patch makes instruction-referencing accepts an additional scenario
where values can be read from physical registers at the start of blocks. As
far as I was aware, this only happened:
* With arguments in the entry block,
* With constant physical registers,
To which this patch adds a third case:
* With exception-handling landing-pad blocks
In the attached test: the operand of the dbg.value traces back to the
"landingpad" instruction, which becomes some copies from physregs. Right
now, that's deemed unacceptable, and the assertion fires. The fix is to
just accept this scenario; this is a case where the value in question is
defined by a register and a position, not by an instruction that defines
it. Reading it with a DBG_PHI is the correct behaviour, there isn't a
non-copy instruction that we can refer to.
Differential Revision: https://reviews.llvm.org/D109005
We keep a map from function name to source location so we don't have to
do it via looking up a source location from the AST. However, since
function names can be long, we actually use a hash of the function name
as the key.
Additionally, we can't rely on Clang's printing of function names via
the AST, so we just demangle the name instead.
This is necessary to implement
https://lists.llvm.org/pipermail/cfe-dev/2021-September/068930.html.
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D110665
When we check if a load is loop invariant by finding a dominating
invariant.start call, we strip bitcasts until we get to an i8* Value,
and look for an invariant.start use of the i8* Value.
We may accidentally end up at an i8 global and look at a global's uses,
which we shouldn't do in a loop pass. Although we could make this
logic work with globals, that's not currently intended.
Reviewed By: nikic
Differential Revision: https://reviews.llvm.org/D111098
Per the GCC info page:
If the function is declared 'extern', then this definition of the
function is used only for inlining. In no case is the function
compiled as a standalone function, not even if you take its address
explicitly. Such an address becomes an external reference, as if
you had only declared the function, and had not defined it.
Respect that behavior for inline builtins: keep the original definition, and
generate a copy of the declaration suffixed by '.inline' that's only referenced
in direct call.
This fixes holes in c3717b6858.
Differential Revision: https://reviews.llvm.org/D111009
This fixes some typos in OpDefinitions.md and DeclarativeRewrites.md,
and wrap function/class names in backticks.
Reviewed By: mehdi_amini
Differential Revision: https://reviews.llvm.org/D110582
A bunch of MTE tests like ./ScudoUnitTest-aarch64-Test/MemtagTest.StoreTags
can fail on aarch64-linux if the kernel doesn't support the tagged address ABI. It looks like
the call to prctl(PR_GET_TAGGED_ADDR_CTRL, 0, 0, 0, 0) can return -1, which
casted to an unsigned int and masked will return a value not equal to
PR_MTE_TCF_NONE, meaning systemDetectsMemoryTagFaultsTestOnly can return an incorrect value.
This updates the check to account for a failing prctl call.
Differential Revision: https://reviews.llvm.org/D110888
When determining NoAlias based on object size and dereferenceability
information, we can ignore frees for the same reason we can ignore
possible null pointers (if null is not a valid pointer): Actually
accessing the null pointer / freed pointer would be immediate UB,
and AA results are only valid under the assumption of an access.
This addresses a minor regression from D110745.
Differential Revision: https://reviews.llvm.org/D111028
The builtins: `__compare_and_swaplp`, `__fetch_and_addlp`,
` __fetch_and_andlp`, `__fetch_and_orlp`, `__fetch_and_swaplp` are
64 bit only. This patch ensures the compiler produces an error in 32 bit mode.
Reviewed By: #powerpc, nemanjai
Differential Revision: https://reviews.llvm.org/D110824
The delayed stack protector feature which is currently used for SDAG (and thus
allows for more commonly generating tail calls) depends on being able to extract
the tail call into a separate return block. To do this it also has to extract
the vreg->physreg copies that set up the call's arguments, since if it doesn't
then the call inst ends up using undefined physregs in it's new spliced block.
SelectionDAG implementations can do this because they delay emitting register
copies until *after* the stack arguments are set up. GISel however just
processes and emits the arguments in IR order, so stack arguments always end up
last, and thus this breaks the code that looks for any register arg copies that
precede the call instruction.
This patch adds a thunk argument to the assignValueToReg() and custom assignment
hooks. For outgoing arguments, register assignments use this return param to
return a thunk that does the actual generating of the copies. We collect these
until all the outgoing stack assignments have been done and then execute them,
so that the copies (and perhaps some artifacts like G_SEXTs) are placed after
any stores.
Differential Revision: https://reviews.llvm.org/D110610
