If a simplication occurs the operand will be added to the worklist.
But since the demanded mask was based on N, we need to make sure
we revisit N in case there are more simplifications to be done.
Returning SDValue(N, 0) as we do, only tells DAG combine that
something changed, but that won't make it add anything to the
worklist.
Found while playing around with using VEXTRACT_STORE in more cases.
But I guess this doesn't affect any of our existing tests.
We can use MOVLPS which will load 64 bits, but we need a v4f32
result type. We already have isel patterns for this.
The code here is a little hacky. We can probably improve it with
more isel patterns.
This is similar to using movd which we do for sse2 targets.
I've added a DAG combine for VEXTRACT_STORE to use SimplifyDemandedVectorElts
to clean up some artifacts from type legalization.
The GenericLLVMIRPlatformSupport class runs a transform on all LLVM IR added to
the LLJIT instance to replace instances of llvm.global_ctors with a specially
named function that runs the corresponing static initializers (See
(GlobalCtorDtorScraper from lib/ExecutionEngine/Orc/LLJIT.cpp). This patch
updates the GenericIRPlatform class to check for this specially named function
in other materialization units that are added to the JIT and, if found, add
the function to the initializer work queue. Doing this allows object files
that were compiled from IR and cached to be reloaded in subsequent JIT sessions
without their initializers being skipped.
To enable testing this patch also updates the lli tool's -jit-kind=orc-lazy mode
to respect the -enable-cache-manager and -object-cache-dir options, and modifies
the CompileOnDemandLayer to rename extracted submodules to include a hash of the
names of their symbol definitions. This allows a simple object caching scheme
based on module names (which was already implemented in lli) to work with the
lazy JIT.
This patch adds new errors and error checking to the ObjectLinkingLayer to
catch cases where a compiled or loaded object either:
(1) Contains definitions not covered by its responsibility set, or
(2) Is missing definitions that are covered by its responsibility set.
Proir to this patch providing the correct set of definitions was treated as
an API contract requirement, however this requires that the client be confident
in the correctness of the whole compiler / object-cache pipeline and results
in difficult-to-debug assertions upon failure. Treating this as a recoverable
error results in clearer diagnostics.
The performance overhead of this check is one comparison of densemap keys
(symbol string pointers) per linking object, which is minimal. If this overhead
ever becomes a problem we can add the check under a flag that can be turned off
if the client fully trusts the rest of the pipeline.
The diagnostic added in D72231 also shows a diagnostic when casting to a
_Bool. This is unwanted. This patch removes the diagnostic for _Bool types.
Differential Revision: https://reviews.llvm.org/D74860
With this --shuffle-sections=seed produces the same result in every
host.
Reviewed By: grimar, MaskRay
Differential Revision: https://reviews.llvm.org/D74971
D74764 (https://reviews.llvm.org/rG31f2ad9c368d47721508cbd0d120d626f9041715)
changed the behavior of the yaml2obj. Now it assigns virtual addresses
for allocatable sections.
SymbolFile/Breakpad/symtab.test started to fail after this change:
(http://lab.llvm.org:8011/builders/lldb-x86_64-debian/builds/5520/steps/test/logs/stdio)
Command Output (stderr):
--
/home/worker/lldb-x86_64-debian/lldb-x86_64-debian/llvm-project/lldb/test/Shell/SymbolFile/Breakpad/symtab.test:6:10: error: CHECK: expected string not found in input
# CHECK: Symtab, file = {{.*}}symtab.out, num_symbols = 5:
^
<stdin>:15:1: note: scanning from here
Symtab, file = /home/worker/lldb-x86_64-debian/lldb-x86_64-debian/build/tools/lldb/test/SymbolFile/Breakpad/Output/symtab.out, num_symbols = 6:
^
<stdin>:15:99: note: possible intended match here
Symtab, file = /home/worker/lldb-x86_64-debian/lldb-x86_64-debian/build/tools/lldb/test/SymbolFile/Breakpad/Output/symtab.out, num_symbols = 6:
For now I've updated the basic-elf.yaml so that now it produce the same layout as before D74764.
Breakpad/symtab.test should be updated it seems.
I've noticed that it is not convenient to create YAMLs from
binaries (using obj2yaml) that have to be test cases for obj2yaml
later (after applying yaml2obj).
The problem, for example is that obj2yaml emits "DynamicSymbols:"
key instead of .dynsym. It also does not create .dynstr.
And when a YAML document without explicitly defined .dynsym/.dynstr
is given to yaml2obj, we have issues:
1) These sections are placed after non-allocatable sections (I've fixed it in D74756).
2) They have VA == 0. User needs create descriptions for such sections explicitly manually
to set a VA.
This patch addresses (2). I suggest to let yaml2obj assign virtual addresses by itself.
It makes an output binary to be much closer to "normal" ELF.
(It is still possible to use "Address: 0x0" for a section to get the original behavior
if it is needed)
Differential revision: https://reviews.llvm.org/D74764
Make Clang on aarch64 targets predefine `__AARCH64_CMODEL_SMALL__`
or `__AARCH64_CMODEL_TINY__`, etc. These are the names that GCC
uses for its predefines.
Reviewed By: tamur, MaskRay
Differential Revision: https://reviews.llvm.org/D75002
Summary:
Added fuzzing test for strcpy and some documentation related to fuzzing.
This will be the first step in integrating this with oss-fuzz.
Reviewers: sivachandra, abrachet
Reviewed By: sivachandra, abrachet
Subscribers: gchatelet, abrachet, mgorny, MaskRay, tschuett, libc-commits
Tags: #libc-project
Differential Revision: https://reviews.llvm.org/D74091
Similar to what do for other operations that use a subset of bits.
Allows us to remove a pattern that shrinks a load. Which was
incorrect if the load was volatile.
Added two flags to omit uncommon or dead paths in the CFG graphs:
-cfg-hide-unreachable-paths
-cfg-hide-deoptimize-paths
The main purpose is performance analysis when such block are not
"interesting" from perspective of common path performance.
Reviewed By: apilipenko, davidxl
Differential Revision: https://reviews.llvm.org/D74346
Summary:
We already sorted the blocks when fixing up a set of mutual
loop entries, however, there can be multiple sets of such
mutual loop entries, and the order we encounter them
should not be random, so sort them too.
Fixes https://bugs.llvm.org/show_bug.cgi?id=44982
Patch by Alon Zakai (kripken)
Reviewers: aheejin, sbc100, dschuff
Subscribers: mgrang, sunfish, hiraditya, jgravelle-google, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D74999
Summary:
This is another attempt of 0bb90628b5.
The difference is that g_python_home is not declared as const. Since
some versions of python do not expect that.
Subscribers: mgorny, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74998
Similar to the rest of the command line that is recorded, the program
path must also have spaces and backslashes escaped. Without this
parsing the recorded command line becomes hard on platforms like
Windows where spaces and backslashes are common.
This was originally reverted in
577d9ce35532439203411c999deefc9c80e04c69; this version makes a test
agnostic to the presence of backslashes in paths on some platforms.
Patch By: Ravi Ramaseshan
Differential Revision: https://reviews.llvm.org/D74811
This reverts commit 977cd661cf.
It breaks OpenCL testing. OpenCL Runtime is using PT_LOAD information
to calculate memory for global variables. This commit should be relanded once
the OpenCL runtime stops relying on PT_LOAD information for calculating global
variable memory size.
Differential Revision: https://reviews.llvm.org/D74995
On Apple platforms, is __arm__ isn't defined and we're not on Intel, we use an
alternate std::string layout. I.e., the libcxx string test fails on phones
because the hand-crafted "garbage" string structs are actually valid strings.
See:
```
// _LIBCPP_ALTERNATE_STRING_LAYOUT is an old name for
// _LIBCPP_ABI_ALTERNATE_STRING_LAYOUT left here for backward compatibility.
#if (defined(__APPLE__) && !defined(__i386__) && !defined(__x86_64__) && \
(!defined(__arm__) || __ARM_ARCH_7K__ >= 2)) || \
defined(_LIBCPP_ALTERNATE_STRING_LAYOUT)
#define _LIBCPP_ABI_ALTERNATE_STRING_LAYOUT
#endif
```
Disable inspection of the garbage structs on Apple+ARM devices.
Heads-up message: https://lists.llvm.org/pipermail/llvm-dev/2020-February/139390.html
GNU as started to emit warnings for changed sh_type or sh_flags in 2000.
GNU as>=2.35 will emit errors for most sh_type/sh_flags change, and error for entsize change.
Some cases remain warnings for legacy reasons:
.section .init_array,"ax", @progbits
.section .init_array,"ax", @init_array
# And some obscure sh_flags changes (OS/Processor specific flags)
The rationale of a diagnostic (warning or error) is that sh_type,
sh_flags or sh_entsize changes usually indicate user errors. The values
are taken from the first .section directive. Successive directives are ignored.
We just try to be rigid and emit errors for all sh_type/sh_flags/sh_entsize change.
A possible improvement in the future is to reuse
llvm-readobj/ELFDumper.cpp:getSectionTypeString so that we can name the
type in the diagnostics.
Reviewed By: psmith
Differential Revision: https://reviews.llvm.org/D73999
Summary:
GNU objdump prints the method name in disassembly output, and upon further investigation this seems to come from debug info, not the symbol table.
Some additional refactoring is necessary to make this work even when the line number is 0/the filename is unknown. The added test case includes a note for this scenario.
See http://llvm.org/PR41341 for more info.
Reviewers: dblaikie, MaskRay, jhenderson
Reviewed By: MaskRay
Subscribers: ormris, jvesely, aprantl, kerbowa, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D74507
Summary:
This details the C++ format as well as the new declarative format. This has been one of the major missing pieces from the toy tutorial.
Differential Revision: https://reviews.llvm.org/D74938
This revision add support for formatting successor variables in a similar way to operands, attributes, etc.
Differential Revision: https://reviews.llvm.org/D74789
This revision add support in ODS for specifying the successors of an operation. Successors are specified via the `successors` list:
```
let successors = (successor AnySuccessor:$target, AnySuccessor:$otherTarget);
```
Differential Revision: https://reviews.llvm.org/D74783
This range is useful when an desired API expects a range or when comparing two different ranges for equality, but the underlying data is a splat. This range removes the need to explicitly construct a vector in those cases.
Differential Revision: https://reviews.llvm.org/D74683
This matches the '(print|parse)OptionalAttrDictWithKeyword' functionality provided by the assembly parser/printer.
Differential Revision: https://reviews.llvm.org/D74682
When operations have optional attributes, or optional operands(i.e. empty variadic operands), the assembly format often has an optional section to represent these arguments. This revision adds basic support for defining an "optional group" in the assembly format to support this. An optional group is defined by wrapping a set of elements in `()` followed by `?` and requires the following:
* The first element of the group must be either a literal or an operand argument.
- This is because the first element must be optionally parsable.
* There must be exactly one argument variable within the group that is marked as the anchor of the group. The anchor is the element whose presence controls whether the group should be printed/parsed. An element is marked as the anchor by adding a trailing `^`.
* The group must only contain literals, variables, and type directives.
- Any attribute variables may be used, but only optional attributes can be marked as the anchor.
- Only variadic, i.e. optional, operand arguments can be used.
- The elements of a type directive must be defined within the same optional group.
An example of this can be seen with the assembly format for ReturnOp, which has a variadic number of operands.
```
def ReturnOp : ... {
let arguments = (ins Variadic<AnyType>:$operands);
// We only print the operands+types if there are a non-zero number
// of operands.
let assemblyFormat = "attr-dict ($operands^ `:` type($operands))?";
}
```
Differential Revision: https://reviews.llvm.org/D74681
This allows for injecting type constraints that are not direct 1-1 mappings, for example when one type is equal to the element type of another. This allows for moving over several more parsers to the declarative form.
Differential Revision: https://reviews.llvm.org/D74648
Recently I had to use it and although one assumes it returns null if
there's no parent loop, I think it helps to doc it.
Reviewed By: Meinersbur
Differential Revision: https://reviews.llvm.org/D74890
Sam McCall