The Flang driver depends on libclangBasic. This means, among other
things, that some of the tablegen files (e.g. diagnostic definitions)
need to be generated before various libclangBasic header files can be
included (e.g. DiagnosticIDs.h). If we are lucky, libclangBasic is
indeed built before various flang driver libraries that depend on it
are. This patch makes sure that this is deterministic - i.e.
libclangBasic is built before the Flang driver libraries are.
Differential Revision: https://reviews.llvm.org/D88110
In the frontend driver we should be using FC1Option (frontend driver
options) instead of FlangOption (flang driver options).
Differential Revision: https://reviews.llvm.org/D88108
This takes the mapped instructions from the IRInstructionMapper, and
passes it to the Suffix Tree to find the repeated substrings. Within
each set of repeated substrings, the IRSimilarityCandidates are compared
against one another for structure, and ensuring that the operands in the
instructions are used in the same way. Each of these structurally
similarity IRSimilarityCandidates are contained in a SimilarityGroup.
Tests checking for identifying identity of structure, different
isomorphic structure, and different
nonisomoprhic structure are found in
unittests/Analysis/IRSimilarityIdentifierTest.cpp.
Differential Revision: https://reviews.llvm.org/D86972
This patch makes the 'ExtLen' field of extended opcodes optional. We
don't need to manually calculate it in the future.
Reviewed By: jhenderson, MaskRay
Differential Revision: https://reviews.llvm.org/D88136
Since DWARFv5 places TUs in debug_info, some of DWARFContext's APIs have
become a bit erroneous, including TUs in the CU list by accident.
Correct that by providing compile_units (& dwo_compile_units) that
filter out the type units from the debug_info units.
Differential Revision: https://reviews.llvm.org/D87935
Flag DIEs that have DW_CHILDREN_yes set in their abbreviation but don't
actually have any children.
rdar://59809554
Differential revision: https://reviews.llvm.org/D88048
This patch implements custom codegen for the vec_replace_elt and
vec_replace_unaligned builtins.
These builtins map to the @llvm.ppc.altivec.vinsw and @llvm.ppc.altivec.vinsd
intrinsics depending on the arguments. The main motivation for doing custom
codegen for these intrinsics is because there are float and double versions of
the builtin. Normally, the converting the float to an integer would be done via
fptoui in the IR. This is incorrect as fptoui truncates the value and we must
ensure the value is not truncated. Therefore, we provide custom codegen to utilize
bitcast instead as bitcasts do not truncate.
Differential Revision: https://reviews.llvm.org/D83500
Just because sequences of instructions are similar to one another,
doesn't mean they are doing the same thing.
This introduces a structural check for the IRSimilarityCandidate that
compares two IRSimilarityCandidates against one another, and in each
instruction creates a mapping between the operands and results, or
checks that the existing mapping is valid. If this check passes, it
means we have structurally similar IRSimilarityCandidates.
Tests for whether the candidates are found in
unittests/Analysis/IRSimilarityIdentifierTest.cpp.
Recommit of: b27db2bb68 for Differential
URL.
Differential Revision: https://reviews.llvm.org/D86971
Just because sequences of instructions are similar to one another,
doesn't mean they are doing the same thing.
This introduces a structural check for the IRSimilarityCandidate that
compares two IRSimilarityCandidates against one another, and in each
instruction creates a mapping between the operands and results, or
checks that the existing mapping is valid. If this check passes, it
means we have structurally similar IRSimilarityCandidates.
Tests for whether the candidates are found in
unittests/Analysis/IRSimilarityIdentifierTest.cpp.
* Move computation of systemLibraryRoots into a separate function, so we
can add more functionality to it without things becoming unwieldy
* Have `getSearchPaths` and related functions return by value instead of
by output parameter. NRVO should ensure that performance is unaffected.
Reviewed By: #lld-macho, smeenai
Differential Revision: https://reviews.llvm.org/D87959
They cause their corresponding libraries / frameworks to be loaded via
`LC_LOAD_WEAK_DYLIB` instead of `LC_LOAD_DYLIB`.
Reviewed By: #lld-macho, gkm
Differential Revision: https://reviews.llvm.org/D87929
Handle the case where there are both common and non-common definitions
of the same symbol. Add a bunch of tests to ensure compatibility with ld64.
Reviewed By: #lld-macho, gkm
Differential Revision: https://reviews.llvm.org/D86910
On Unix, it is traditionally allowed to write variable definitions without
initialization expressions (such as "int foo;") to header files. These are
called tentative definitions.
The compiler creates common symbols when it sees tentative definitions. When
linking the final binary, if there are remaining common symbols after name
resolution is complete, the linker converts them to regular defined symbols in
a `__common` section.
This diff implements most of that functionality, though we do not yet handle
the case where there are both common and non-common definitions of the same
symbol.
Reviewed By: #lld-macho, gkm
Differential Revision: https://reviews.llvm.org/D86909
Fix the verifier so that overlapping SGPR operands are counted
independently. We cannot assume that overlapping SGPR accesses
only count as a single constant bus use.
The exception is implicit uses which do not add to constant bus
usage (only) when overlapping.
Reviewed By: rampitec
Differential Revision: https://reviews.llvm.org/D87748
Used by kexec-tools (PR46942)
In GNU as, tc-i386.c:output_jump uses 4-byte immediate if a data32 prefix is present.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D88137
The OS version field is generally not very helpful for non-Darwin
targets. On Linux, it identifies the kernel version which moves
out-of-sync with the userspace. On Windows, this field actually ends up
corresponding to the Visual Studio toolset version instead of the OS
version. Consider non-Darwin targets without an OS version to be fully
specified.
Differential Revision: https://reviews.llvm.org/D88181
Reviewed By: Jonas Devlieghere, Dave Lee
As of cmake 3.18, cmake changes how it searches for compilers for
Windows (see
55196a1440)
and now finds llvm-ar instead of llvm-lib as CMAKE_AR. This explicitly
specifies CMAKE_AR as llvm-lib so the correct program is found.
Reviewed By: smeenai
Differential Revision: https://reviews.llvm.org/D88176
Translating between JSON objects and C++ strutctures is common.
From experience in clangd, fromJSON/ObjectMapper work well and save a lot of
code, but aren't adopted elsewhere at least partly due to total lack of error
reporting beyond "ok"/"bad".
The recently-added error model should be rich enough for most applications.
It requires tracking the path within the root object and reporting local
errors at appropriate places.
To do this, we exploit the fact that the call graph of recursive
parse functions mirror the structure of the JSON itself.
The current path is represented as a linked list of segments, each of which is
on the stack as a parameter. Concretely, fromJSON now looks like:
bool fromJSON(const Value&, T&, Path);
Beyond the signature change, this is reasonably unobtrusive: building
the path segments is mostly handled by ObjectMapper and the vector<T> fromJSON.
However the root caller of fromJSON must now create a Root object to
store the errors, which is a little clunky.
I've added high-level parse<T>(StringRef) -> Expected<T>, but it's not
general enough to be the primary interface I think (at least, not usable in
clangd).
All existing users (mostly just clangd) are updated in this patch,
making this change backwards-compatible is a bit hairy.
Differential Revision: https://reviews.llvm.org/D88103
Currently, findUnwindSectionsByPhdr is slightly micro-optimized for the
case where the first callback has the target address, and is otherwise
very inefficient -- it decodes .eh_frame_hdr even when no PT_LOAD
matches the PC. (If the FrameHeaderCache is enabled, then the
micro-optimization only helps the first time unwind info is looked up.)
Instead, it makes more sense to optimize for the case where the
callback *doesn't* find the target address, so search for a PT_LOAD
segment first, and only look for the unwind info section if a matching
PT_LOAD is found.
This change helps on an Android benchmark with 100 shared objects,
where the DSO at the end of the dl_iterate_phdr list throws 10000
exceptions. Assuming the frame cache is disabled, this change cuts
about 30-40% off the benchmark's runtime.
Reviewed By: compnerd, saugustine, #libunwind
Differential Revision: https://reviews.llvm.org/D87881
dl_iterate_phdr is used to search for unwind info provided by either
PT_GNU_EH_FRAME or PT_ARM_EXIDX. Most of the code between the two is
the same, so combine them, and factor out what's different into
checkForUnwindInfoSegment.
Details:
- The FrameHeaderCache can now be enabled for ARM EHABI.
- findUnwindSectionsByPhdr now finds the last PT_ARM_EXIDX rather than
the first. There should only be one segment.
- The dso_base and text_segment_length fields of UnwindInfoSections
are now needed for dl_iterate_phdr when using EHABI, to hold the
low and high PC values for a cache entry.
Reviewed By: compnerd, danielkiss, #libunwind, saugustine
Differential Revision: https://reviews.llvm.org/D87880
When an error occurs processing a JSON object, seeing the actual
surrounding data helps. Dumping just the node where the problem
was identified can be too much or too little information.
printErrorContext() shows the error message in its context, as a comment.
JSON values along the path to the broken place are shown in some detail,
the rest of the document is elided. For example:
```
{
"credentials": [
{
"username": /* error: expected string */ 42,
"password": "secret"
},
{ ... }
]
"backups": { ... }
}
```
Differential Revision: https://reviews.llvm.org/D88103
This is in preparation for supporting -debugify-each, which adds a debug
info pass before and after each pass.
Switch VerifyEach to use this.
Reviewed By: ychen
Differential Revision: https://reviews.llvm.org/D88107
This seems to fit the CGSCC updates model better than calling
addNewFunctionInto{Ref,}SCC() on newly created/outlined functions.
Now addNewFunctionInto{Ref,}SCC() are no longer necessary.
However, this doesn't work on newly outlined functions that aren't
referenced by the original function. e.g. if a() was outlined into b()
and c(), but c() is only referenced by b() and not by a(), this will
trigger an assert.
This also fixes an issue I was seeing with newly created functions not
having passes run on them.
Ran check-llvm with expensive checks.
Reviewed By: asbirlea
Differential Revision: https://reviews.llvm.org/D87798
This error model should be rich enough for most applications. It comprises:
- a name for the root object, so the user knows what we're parsing
- a path from the root object to the JSON node most associated with the error
- a local error message
This can be presented as an llvm::Error e.g.
"expected string at ConfigFile.credentials[0].username"
It's designed to be cheap: Paths are a linked list of lightweight
objects on the stack. No heap allocations unless errors are encountered.
A subsequent commit will make use of this in the JSON-to-object
translation facilities: fromJSON and ObjectMapper.
However it's independent of these and can be used for e.g. validation alone.
Another subsequent commit will support showing the error in its context
within the parsed value.
Differential Revision: https://reviews.llvm.org/D88103
I believe the inline asm emitted here should have a memory clobber since it writes to memory.
It was also missing the dirflag clobber that we use by default along with flags and fpsr. To avoid missing defaults in the future, get the default list from the target
Differential Revision: https://reviews.llvm.org/D88121
Remove all spurious `HelpHidden` flags from `lld/MachO/Options.td`. Add test for `HelpHidden` to `warnIfUnimplementedOption()` so that the empty `// handled elsewhere` case is unnecessary.
Reviewed By: #lld-macho, int3, smeenai
Differential Revision: https://reviews.llvm.org/D88160
This isn't standard JSON, but is a popular extension.
It will be used to show errors in context, rendering pseudo-json for humans.
Differential Revision: https://reviews.llvm.org/D88103
Previously, if a floating-point type was legal, but FNEG wasn't legal,
we would use FSUB. Instead, we should use integer ops, to preserve the
semantics. (Alternatively, there's a compiler-rt call we could use, but
there isn't much reason to use that.)
It turns out we actually are still using this obscure codepath in a few
cases: on some targets, we have "legal" floating-point types that don't
actually support any floating-point operations. In particular, ARM and
AArch64 are using this path.
The implementation for SelectionDAG is pretty simple because we can
reuse the infrastructure from FCOPYSIGN.
See also 9a3dc3e, the corresponding change to type legalization.
Also includes a "bonus" change to STRICT_FSUB legalization, so we can
lower a STRICT_FSUB to a float libcall.
Includes the changes to both LegalizeDAG and GlobalISel so we don't have
inconsistent results in the future.
Fixes https://bugs.llvm.org/show_bug.cgi?id=46792 .
Differential Revision: https://reviews.llvm.org/D84287
With the exception of VECREDUCE_ADD, there are no NEON instructions to support vector of i64 reductions. This patch removes the Custom lowerings for those and adds some test coverage to confirm.
Differential Revision: https://reviews.llvm.org/D88161
Sam McCall