Xing GUO [Wed, 6 Mar 2019 01:28:40 +0000 (01:28 +0000)]
[BinaryFormat] Add DT_USED tag into dynamic section.
Summary:
This tag is documented in https://docs.oracle.com/cd/E19253-01/817-1984/chapter6-42444/index.html
Though I could not find some docs that describe it in detail, I found some code snippets.
1.
```
/*
* Look up the string in the string table and get its offset. If
* this succeeds, then it is possible that there is a DT_NEEDED
* dynamic entry that references it.
*/
have_string = elfedit_sec_findstr(argstate->str.sec,
strpad_elt.dn_dyn.d_un.d_val, arg, &str_offset) != 0;
if (have_string) {
dyn = argstate->dynamic.data;
for (ndx = 0; ndx < numdyn; dyn++, ndx++) {
if (((dyn->d_tag == DT_NEEDED) ||
(dyn->d_tag == DT_USED)) &&
(dyn->d_un.d_val == str_offset))
goto done;
}
}
```
https://github.com/kofemann/opensolaris/blob/80192cd83bf665e708269dae856f9145f7190f74/usr/src/cmd/sgs/elfedit/modules/common/syminfo.c#L512
2.
```
case DT_USED:
case DT_INIT_ARRAY:
case DT_FINI_ARRAY:
if (do_dynamic)
{
if (entry->d_tag == DT_USED
&& VALID_DYNAMIC_NAME (entry->d_un.d_val))
{
char *name = GET_DYNAMIC_NAME (entry->d_un.d_val);
[DWARFFormValue] Don't consider DW_FORM_data4/8 to be section offsets.
When dumping ToT clan's debug info with dwarfdump, we were seeing an
error saying that that the location list overflows the debug_loc
section. After reducing the testcase we figured out that we were
interpreting the DW_FORM_data4 as a section offset.
In DWARF3 DW_FORM_data4 and DW_FORM_data8 served also as a section
offset. Until now we didn't check check for the DWARF version, because
some producers (read old versions of clang) were still emitting this.
The relevant code/comment was added in 2013, and I believe it's now
reasonable to start checking the version.
The FormValue class is a little bit of a mess because it cashes the
DWARF unit and context when it extracted the value itself. Several
methods of the class rely on it being present, or return an Optional for
the code path that needs it. At the same time the FormValue class also
used in places where there's no DWARF unit.
For this patch I went with the least invasive change: checking the
version from the CU when it's available. If it's not (because the form
value was created from a value directly) we default to the old behavior.
Philip Reames [Tue, 5 Mar 2019 23:00:14 +0000 (23:00 +0000)]
[AtomicExpand] Allow libcall expansion for non-zero address spaces
Be consistent about how we treat atomics in non-zero address spaces. If we get to the backend, we tend to lower them as if in address space 0. Do the same if we need to insert a libcall instead.
Roman Lebedev [Tue, 5 Mar 2019 22:43:53 +0000 (22:43 +0000)]
[X86][NFC] Add proper test for promotion of i8 cmov's of trunc's
There was no proper test for that code in X86TargetLowering::LowerSELECT().
Noticed accidentally while trying to modify the last branch in that function.
Heejin Ahn [Tue, 5 Mar 2019 21:05:09 +0000 (21:05 +0000)]
[WebAssembly] Simplify iterator navigations (NFC)
Summary:
- Replaces some uses of `MachineFunction::iterator(MBB)` with
`MBB->getIterator()` and `MachineBasicBlock::iterator(MI)` with
`MI->getIterator()`, which are simpler.
- Replaces some uses of `std::prev` of `std::next` that takes a
MachineFunction or MachineBasicBlock iterator with `getPrevNode` and
`getNextNode`, which are also simpler.
Heejin Ahn [Tue, 5 Mar 2019 20:35:34 +0000 (20:35 +0000)]
[WebAssembly] Disable MachineBlockPlacement pass
Summary:
This pass hurts code size for wasm and sometimes generates irreducible
control flow.
Context: https://github.com/emscripten-core/emscripten/pull/8233
Craig Topper [Tue, 5 Mar 2019 19:18:16 +0000 (19:18 +0000)]
Revert r355224 "[TableGen][SelectionDAG][X86] Add specific isel matchers for immAllZerosV/immAllOnesV. Remove bitcasts from X86 patterns that are no longer necessary."
This caused the first matcher in the isel table for many targets to Opc_Scope instead of Opc_SwitchOpcode. This leads to a significant increase in isel match failures.
Guozhi Wei [Tue, 5 Mar 2019 18:54:34 +0000 (18:54 +0000)]
[X86] In X86DomainReassignment.cpp add enclosed registers to EnclosedEdges
The variable X86DomainReassignment::EnclosedEdges is used to store registers that have been enclosed in some closure, so those registers will be ignored when create new closures. But there is no registers has ever been put into this set, so a single register can be enclosed in multiple closures, it significantly increase compile time.
This patch adds a register into EnclosedEdges when it is enclosed into a closure.
Craig Topper [Tue, 5 Mar 2019 18:54:34 +0000 (18:54 +0000)]
[Subtarget] Create a separate SubtargetSubtargetKV struct for ProcDesc to remove fields from the stack tables that aren't needed for CPUs
The description for CPUs was just the CPU name wrapped with "Select the " and " processor". We can just do that directly in the help printer instead of making a separate version in the binary for each CPU.
Also remove the Value field that isn't needed and was always 0.
Craig Topper [Tue, 5 Mar 2019 18:54:30 +0000 (18:54 +0000)]
[Subtarget] Move SubtargetFeatureKV/SubtargetInfoKV from SubtargetFeature.h to MCSubtargetInfo.h. Move all code that operates on ProcFeatures and ProcDesc arrays to MCSubtargetInfo.
The SubtargetFeature class managed a list of features as strings. And it also had functions for setting bits in a FeatureBitset.
The methods that operated on the Feature list as strings are used in other parts of the backend. But the parts that operate on FeatureBitset are very tightly coupled to MCSubtargetInfo and requires passing in the arrays that MCSubtargetInfo owns. And the same struct type is used for ProcFeatures and ProcDesc.
This has led to MCSubtargetInfo having 2 arrays keyed by CPU name. One containing a mapping from a CPU name to its features. And one containing a mapping from CPU name to its scheduler model.
I would like to make a single CPU array containing all CPU information and remove some unneeded fields the ProcDesc array currently has. But I don't want to make SubtargetFeatures.h have to know about the scheduler model type and have to forward declare or pull in the header file.
Florian Hahn [Tue, 5 Mar 2019 17:56:35 +0000 (17:56 +0000)]
[SLP] Fix invalid triple in X86 tests
x86-64 is an invalid architecture in triples. Changing it to the correct
triple (x86_64) changes some tests, because SLP is not deemed profitable
any more.
George Rimar [Tue, 5 Mar 2019 13:07:43 +0000 (13:07 +0000)]
[llvm-objcopy] - Simplify `isCompressable` and fix the issue relative.
When --compress-debug-sections is given, llvm-objcopy do not compress
sections that have "ZLIB" header in data. Normally this signature is used
in zlib-gnu compression format. But if zlib-gnu used then the name of the compressed
section should start from .z* (e.g .zdebug_info). If it does not, then it is not
a zlib-gnu format and section should be treated as a normal uncompressed section.
David Green [Tue, 5 Mar 2019 12:12:18 +0000 (12:12 +0000)]
[SCEV] Ensure that isHighCostExpansion takes into account what is being divided
A SCEV is not low-cost just because you can divide it by a power of 2. We need to also
check what we are dividing to make sure it too is not a high-code expansion. This helps
to not expand the exit value of certain loops, helping not to bloat the code.
The change in no-iv-rewrite.ll is reverting back to what it was testing before rL194116,
and looks a lot like the other tests in replace-loop-exit-folds.ll.
George Rimar [Tue, 5 Mar 2019 11:32:14 +0000 (11:32 +0000)]
[llvm-objcopy] - Report "no zlib available" error properly when --compress-debug-sections is used.
If zlib is not available, and --compress-debug-sections is passed,
we want to report an error. Currently, it is only reported for
--compress_debug_sections= form of the option.
Fixes the https://bugs.llvm.org/show_bug.cgi?id=40886.
I do not think there is a way to write a test for this.
Simon Pilgrim [Tue, 5 Mar 2019 10:44:37 +0000 (10:44 +0000)]
Add wildcard support to all update_*_test_checks.py scripts (PR37500)
We can already update multiple files in each update call, this extends it to work with wildcards as well in the same way as update_mca_test_checks.py (to support shells that won't do this for us - windows command prompt etc.)
Oliver Stannard [Tue, 5 Mar 2019 10:42:34 +0000 (10:42 +0000)]
[ARM] Fix select_cc lowering for fp16
When lowering a select_cc node where the true and false values are of type f16,
we can't use a general conditional move because the FP16 instructions do not
support conditional execution. Instead, we must ensure that the condition code
is one of the four supported by the VSEL instruction.
Xing GUO [Tue, 5 Mar 2019 03:07:56 +0000 (03:07 +0000)]
[ARM][MC] Update one test case in 'test/MC/Disassembler/ARM/invalid-armv7.txt'
Summary:
Instruction `[0xfe 0xf0 0x20 0xe3]` is a valid instruction on ARM-v7, which is `dbg #14`. See:
https://www.cl.cam.ac.uk/research/srg/han/ACS-P35/zynq/ARMv7-A-R-manual.pdf
(Page: 377)
Craig Topper [Tue, 5 Mar 2019 01:14:25 +0000 (01:14 +0000)]
[X86] Reduce some patterns by using FP instructions for integer types even when AVX2 is available and execution domain fixing will do the right thing
We have quite a few cases of using FP instructions for integer operations when only AVX1 is available. Then we switch to integer instructions with AVX2. In a lot of these cases execution domain fixing will take care of turning FP instructions into integer if its profitable.
With this patch we just keep on using the FP instructions even with AVX2. I've only handled some cases that don't require messing with patterns that are defined in the instruction definition. Those will require more subtle multiclass work possibly involving null_frag, hasSideEffects = 0, etc.
Shoaib Meenai [Tue, 5 Mar 2019 00:38:32 +0000 (00:38 +0000)]
[cmake] Create exports for umbrella library targets
When using the umbrella llvm-libraries and clang-libraries targets, we
should export all library targets, otherwise they'll be part of our
distribution but not usable from the CMake package.
Sanjay Patel [Mon, 4 Mar 2019 22:47:13 +0000 (22:47 +0000)]
[CodeGenPrepare] avoid crashing on non-canonical/degenerate code
The test is reduced from an example in the post-commit thread for:
rL354746
http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20190304/632396.html
While we must avoid dying here, the real question should be:
Why is non-canonical and/or degenerate code making it to CGP when
using the new pass manager?
[GlobalISel][AArch64] Add selection support for G_EXTRACT_VECTOR_ELT
This adds instruction selection support for G_EXTRACT_VECTOR_ELT for cases
where the index is defined by a G_CONSTANT.
It also factos out the lane copy opcode selection part into its own function,
`getLaneCopyOpcode`. This is used by both `selectUnmergeValues` and
`selectExtractElt`.
Shoaib Meenai [Mon, 4 Mar 2019 21:19:53 +0000 (21:19 +0000)]
[build] Rename clang-headers to clang-resource-headers
Summary:
The current install-clang-headers target installs clang's resource
directory headers. This is different from the install-llvm-headers
target, which installs LLVM's API headers. We want to introduce the
corresponding target to clang, and the natural name for that new target
would be install-clang-headers. Rename the existing target to
install-clang-resource-headers to free up the install-clang-headers name
for the new target, following the discussion on cfe-dev [1].
I didn't find any bots on zorg referencing install-clang-headers. I'll
send out another PSA to cfe-dev to accompany this rename.
Sanjay Patel [Mon, 4 Mar 2019 20:57:14 +0000 (20:57 +0000)]
[ConstantHoisting] avoid hang/crash from unreachable blocks (PR40930)
I'm not too familiar with this pass, so there might be a better
solution, but this appears to fix the degenerate:
PR40930
PR40931
PR40932
PR40934
...without affecting any real-world code.
As we've seen in several other passes, when we have unreachable blocks,
they can contain semi-bogus IR and/or cause unexpected conditions. We
would not typically expect these patterns to make it this far, but we
have to guard against them anyway.
Craig Topper [Mon, 4 Mar 2019 19:23:37 +0000 (19:23 +0000)]
[Subtarget] Follow up to r355167, add another set of curly braces to FeatureBitArray initialization to satisfy older versions of clang.
Apparently older versions of clang like 3.6 require an extra set of curly braces around std::array initializations. I'm told the C++ language was changed regarding this by CWG 1270.
Amara Emerson [Mon, 4 Mar 2019 19:16:00 +0000 (19:16 +0000)]
Re-commit r355104: "[AArch64][GlobalISel] Add support for 64 bit vector shuffle using TBL1."
The code to materialize a mask from a constant pool load tried to use a 128 bit
LDR to load a 64 bit constant pool entry, which was 8 byte aligned. This resulted
in a link failure in the NEON tests in the test suite since the LDR address was
unaligned. This change fixes that to instead emit a 64 bit LDR if the entry is
64 bit, before converting back to a 128 bit register for the TBL.
Craig Topper [Mon, 4 Mar 2019 19:12:16 +0000 (19:12 +0000)]
[DAGCombiner][X86][SystemZ][AArch64] Combine some cases of (bitcast (build_vector constants)) between legalize types and legalize dag.
This patch enables combining integer bitcasts of integer build vectors when the new scalar type is legal. I've avoided floating point because the implementation bitcasts float to int along the way and we would need to check the intermediate types for legality
[MCA] Highlight kernel bottlenecks in the summary view.
This patch adds a new flag named -bottleneck-analysis to print out information
about throughput bottlenecks.
MCA knows how to identify and classify dynamic dispatch stalls. However, it
doesn't know how to analyze and highlight kernel bottlenecks. The goal of this
patch is to teach MCA how to correlate increases in backend pressure to backend
stalls (and therefore, the loss of throughput).
From a Scheduler point of view, backend pressure is a function of the scheduler
buffer usage (i.e. how the number of uOps in the scheduler buffers changes over
time). Backend pressure increases (or decreases) when there is a mismatch
between the number of opcodes dispatched, and the number of opcodes issued in
the same cycle. Since buffer resources are limited, continuous increases in
backend pressure would eventually leads to dispatch stalls. So, there is a
strong correlation between dispatch stalls, and how backpressure changed over
time.
This patch teaches how to identify situations where backend pressure increases
due to:
- unavailable pipeline resources.
- data dependencies.
Data dependencies may delay execution of instructions and therefore increase the
time that uOps have to spend in the scheduler buffers. That often translates to
an increase in backend pressure which may eventually lead to a bottleneck.
Contention on pipeline resources may also delay execution of instructions, and
lead to a temporary increase in backend pressure.
Internally, the Scheduler classifies instructions based on whether register /
memory operands are available or not.
An instruction is marked as "ready to execute" only if data dependencies are
fully resolved.
Every cycle, the Scheduler attempts to execute all instructions that are ready
to execute. If an instruction cannot execute because of unavailable pipeline
resources, then the Scheduler internally updates a BusyResourceUnits mask with
the ID of each unavailable resource.
ExecuteStage is responsible for tracking changes in backend pressure. If backend
pressure increases during a cycle because of contention on pipeline resources,
then ExecuteStage sends a "backend pressure" event to the listeners.
That event would contain information about instructions delayed by resource
pressure, as well as the BusyResourceUnits mask.
Note that ExecuteStage also knows how to identify situations where backpressure
increased because of delays introduced by data dependencies.
The SummaryView observes "backend pressure" events and prints out a "bottleneck
report".
A bottleneck report is printed out only if increases in backend pressure
eventually caused backend stalls.
About the time complexity:
Time complexity is linear in the number of instructions in the
Scheduler::PendingSet.
The average slowdown tends to be in the range of ~5-6%.
For memory intensive kernels, the slowdown can be significant if flag
-noalias=false is specified. In the worst case scenario I have observed a
slowdown of ~30% when flag -noalias=false was specified.
We can definitely recover part of that slowdown if we optimize class LSUnit (by
doing extra bookkeeping to speedup queries). For now, this new analysis is
disabled by default, and it can be enabled via flag -bottleneck-analysis. Users
of MCA as a library can enable the generation of pressure events through the
constructor of ExecuteStage.
This patch partially addresses https://bugs.llvm.org/show_bug.cgi?id=37494
Jeremy Morse [Mon, 4 Mar 2019 10:56:02 +0000 (10:56 +0000)]
[X86] Avoid codegen changes when DBG_VALUE appears between lowered selects
X86TargetLowering::EmitLoweredSelect presently detects sequences of CMOV pseudo
instructions without accounting for debug intrinsics. This leads to different
codegen with and without option -g, if a DBG_VALUE instruction lands in the
middle of several lowered selects.
Work around this by skipping over debug instructions when looking for CMOV
sequences, and sinking those debug insts into the EmitLoweredSelect sunk block.
This might slightly shift where variables appear in the instruction sequence,
but won't re-order assignments.
Oliver Stannard [Mon, 4 Mar 2019 09:17:38 +0000 (09:17 +0000)]
[ARM] Fix selection of VLDR.16 instruction with imm offset
The isScaledConstantInRange function takes upper and lower bounds which are
checked after dividing by the scale, so the bounds checks for half, single and
double precision should all be the same. Previously, we had wrong bounds checks
for half precision, so selected an immediate the instructions can't actually
represent.
Jonas Hahnfeld [Mon, 4 Mar 2019 08:51:32 +0000 (08:51 +0000)]
[AArch64/ARM] Fix two compiler warnings in InstructionSelector, NFCI
1) GCC complains that KnownValid is set but not used.
2) In ARMInstructionSelector::selectGlobal() the code is mixing "enumeral
and non-enumeral type in conditional expression". Solve this by casting
to unsigned which is the final type anyway.
Heejin Ahn [Sun, 3 Mar 2019 22:35:56 +0000 (22:35 +0000)]
[WebAssembly] Delete ThrowUnwindDest map from WasmEHFuncInfo
Summary:
Before when we implemented the first EH proposal, 'catch <tag>'
instruction may not catch an exception so there were multiple EH pads an
exception can unwind to. That means a BB could have multiple EH pad
successors.
Now after we switched to the new proposal, every 'catch' instruction
catches an exception, and there is only one catchpad per catchswitch, so
we at most have one EH pad successor, making `ThrowUnwindDest` map in
`WasmEHInfo` unnecessary.
Keeping `ThrowUnwindDest` map in `WasmEHInfo` has its own problems,
because other optimization passes can split a BB that contains possibly
throwing calls (previously invokes), and we have to update the map every
time that happens, which is not easy for common CodeGen passes.
This also correctly updates successor info in LateEHPrepare when we add
a rethrow instruction.
Sanjay Patel [Sun, 3 Mar 2019 18:59:33 +0000 (18:59 +0000)]
[ValueTracking] do not try to peek through bitcasts in computeKnownBitsFromAssume()
There are no tests for this case, and I'm not sure how it could ever work,
so I'm just removing this option from the matcher. This should fix PR40940:
https://bugs.llvm.org/show_bug.cgi?id=40940
Michal Gorny [Sun, 3 Mar 2019 10:06:40 +0000 (10:06 +0000)]
[llvm] [Support] Reimplement getMainExecutable() using sysctl on NetBSD
Use sysctl() to implement getMainExecutable() on NetBSD, rather than
trying to guess the correct path from argv[0]. This is one
of the fixes to recent clang-check-mac-libcxx-fixed-compilation-db.cpp
test failure on NetBSD.
This has been historically done on both FreeBSD and NetBSD in r303015,
and reverted in r303285 due to buggy implementation on FreeBSD.
However, FWIK the NetBSD implementation does not suffer from the same
bugs and is more reliable than playing with argv[0].
Craig Topper [Sun, 3 Mar 2019 00:18:07 +0000 (00:18 +0000)]
[X86] Prefer VPBLENDD for v2i64/v4i64 blends with AVX2.
We were using VPBLENDW for v2i64 and VBLENDPD for v4i64. VPBLENDD has better throughput than VPBLENDW on some CPUs so it makes sense to use it when possible. VBLENDPD will probably become VBLENDD during execution domain fixing, but we might as well use integer in isel while we can.
This should work around some issues with the domain fixing pass prefering PBLENDW when we start with PBLENDW. There may still be some v8i16 cases that could use PBLENDD.
Nico Weber [Sat, 2 Mar 2019 18:29:56 +0000 (18:29 +0000)]
gn build: Add a cfi/sources target.
This build target is currently unused, but after r355144 the sync script
started complaining about cfi.cpp not being listed, and this makes the
script happy again.
Sanjay Patel [Sat, 2 Mar 2019 16:45:10 +0000 (16:45 +0000)]
[InstCombine] move add after smin/smax
Follow-up to rL355221.
This isn't specifically called for within PR14613,
but we'll get there eventually if it's not already
requested in some other bug report.
projects / llvm / log