Roman Lebedev [Mon, 4 Feb 2019 09:12:25 +0000 (09:12 +0000)]
[llvm-exegesis] Cut run time of analysis mode by another -35% (*sic*) (YamlContext::getRegNo())
Summary:
Together with the previous patch, it's an -90% improvement,
or roughly -96% improvement if you look starting with rL347204
```
$ perf stat -r 9 ./bin/llvm-exegesis -mode=analysis -analysis-epsilon=1.0 -benchmarks-file=/tmp/benchmarks-inverse_throughput-onefull.yaml -analysis-clusters-output-file="" -analysis-inconsistencies-output-file=/tmp/clusters-bew.html
no exegesis target for x86_64-unknown-linux-gnu, using default
Parsed 14656 benchmark points
Printing sched class consistency analysis results to file '/tmp/clusters-bew.html'
...
no exegesis target for x86_64-unknown-linux-gnu, using default
Parsed 14656 benchmark points
Printing sched class consistency analysis results to file '/tmp/clusters-bew.html'
Roman Lebedev [Mon, 4 Feb 2019 09:12:21 +0000 (09:12 +0000)]
[llvm-exegesis] Cut run time of analysis mode by -84% (*sic*) (YamlContext::getInstrOpcode())
Summary:
```
$ perf stat -r 9 ./bin/llvm-exegesis -mode=analysis -analysis-epsilon=1.0 -benchmarks-file=/tmp/benchmarks-inverse_throughput-onefull.yaml -analysis-clusters-output-file="" -analysis-inconsistencies-output-file=/tmp/clusters-old.html
no exegesis target for x86_64-unknown-linux-gnu, using default
Parsed 14656 benchmark points
Printing sched class consistency analysis results to file '/tmp/clusters-old.html'
...
no exegesis target for x86_64-unknown-linux-gnu, using default
Parsed 14656 benchmark points
Printing sched class consistency analysis results to file '/tmp/clusters-old.html'
Roman Lebedev [Mon, 4 Feb 2019 09:12:17 +0000 (09:12 +0000)]
[llvm-exegesis] Throughput support in analysis mode
Summary:
D57000 / [[ https://bugs.llvm.org/show_bug.cgi?id=37698 | PR37698 ]] added support for measuring of the inverse throughput.
But the support for the analysis was not added.
This attempts to fix that. (analysis done o bdver2 / piledriver)
First, small-scale experiment:
```
$ ./bin/llvm-exegesis -num-repetitions=10000 -mode=inverse_throughput -opcode-name=BSF64rr
Check generated assembly with: /usr/bin/objdump -d /tmp/snippet-d0acdd.o
---
mode: inverse_throughput
key:
instructions:
- 'BSF64rr RAX RDX'
config: ''
register_initial_values:
- 'RDX=0x0'
cpu_name: bdver2
llvm_triple: x86_64-unknown-linux-gnu
num_repetitions: 10000
measurements:
- { key: inverse_throughput, value: 3.0278, per_snippet_value: 3.0278 }
error: ''
info: instruction has no tied variables picking Uses different from defs
assembled_snippet: 48BA0000000000000000480FBCC2480FBCC2480FBCC2480FBCC2480FBCC2480FBCC2480FBCC2480FBCC2480FBCC2480FBCC2480FBCC2480FBCC2480FBCC2480FBCC2480FBCC2480FBCC2C3
...
```
If we plug `bsfq %r12, %r10` into llvm-mca:
https://godbolt.org/z/ZtOyhJ
```
Dispatch Width: 4
uOps Per Cycle: 3.00
IPC: 0.50
Block RThroughput: 2.0
```
So RThroughput mismatch exists.
Now, let's upscale and analyse:
{F8207148}
`$ ./bin/llvm-exegesis -mode=analysis -analysis-epsilon=1.0 -benchmarks-file=/tmp/benchmarks-inverse_throughput.yaml -analysis-inconsistencies-output-file=/tmp/clusters.html`:
{F8207172}
{F8207197}
And if we now look at https://www.agner.org/optimize/instruction_tables.pdf,
`Reciprocal throughput` for `BSF r,r` is listed as `3`.
Yay?
Roman Lebedev [Mon, 4 Feb 2019 09:12:13 +0000 (09:12 +0000)]
[llvm-exegesis] deserializeMCInst(): bump SmallVector small size up to 16
Summary:
... from 8.
`VALIGNDZ128rmbik XMM0 XMM0 K1 XMM3 RDI i_0x1 i_0x0 i_0x1` instruction already has 9 components.
It does not matter much in terms of performance, but avoiding allocation seems to come with low cost here..
Roman Lebedev [Mon, 4 Feb 2019 09:12:08 +0000 (09:12 +0000)]
[llvm-exegesis] Don't default to running&dumping all analyses to '-'
Summary:
Up until the point i have looked in the source, i didn't even understood that
i can disable 'cluster' output. I have always silenced it via ` &> /dev/null`.
(And hoped it wasn't contributing much of the run time.)
While i expect that it has it's use-cases i never once needed it so far.
If i forget to silence it, console is completely flooded with that output.
How about not expecting users to opt-out of analyses,
but to explicitly specify the analyses that should be performed?
Max Kazantsev [Mon, 4 Feb 2019 05:04:19 +0000 (05:04 +0000)]
[SCEV] Do not bother creating separate SCEVUnknown for unreachable nodes
Currently, SCEV creates SCEVUnknown for every node of unreachable code. If we
have a huge amounts of such code, we will be littering SE with these nodes. We could
just state that they all are undef and save some memory.
Craig Topper [Mon, 4 Feb 2019 04:15:02 +0000 (04:15 +0000)]
Revert r352985 "[X86] Print %st(0) as %st to match what gcc inline asm uses as the clobber name to make MS inline asm work correctly"
Looking into gcc and objdump behavior more this was overly aggressive. If the register is encoded in the instruction we should print %st(0), if its implicit we should print %st.
I'll be making a more directed change in a future patch.
Compute the correct symbol size in llvm-nm even without --print-size
In llvm-nm, the symbol size was being computed only with --print-size option,
even though it was being printed in other cases, such as with --format=posix.
This patch simply removes the guard, so that the size is computed
independently of the later decision to print it or not.
Sanjay Patel [Sun, 3 Feb 2019 17:53:09 +0000 (17:53 +0000)]
[CGP] adjust target constraints for forming uaddo
There are 2 changes visible here:
1. There's no reason to limit this transform based on number
of condition registers. That diff allows PPC to produce
slightly better (dot-instructions should be generally good)
code.
Note: someone that cares about PPC codegen might want to
look closer at that output because it seems like we could
still improve this.
2. We (probably?) should not bother trying to form uaddo (or
other overflow ops) when there's no target support for such
an op. This goes beyond checking whether the op is expanded
because both PPC and AArch64 show better codegen for standard
types regardless of whether the op is legal/custom.
Sanjay Patel [Sun, 3 Feb 2019 16:16:48 +0000 (16:16 +0000)]
[PatternMatch] add special-case uaddo matching for increment-by-one (2nd try)
This is the most important uaddo problem mentioned in PR31754:
https://bugs.llvm.org/show_bug.cgi?id=31754
...but that was overcome in x86 codegen with D57637.
That patch also corrects the inc vs. add regressions seen with the previous attempt at this.
Still, we want to make this matcher complete, so we can potentially canonicalize the pattern
even if it's an 'add 1' operation.
Pattern matching, however, shouldn't assume that we have canonicalized IR, so we match 4
commuted variants of uaddo.
There's also a test with a crazy type to show that the existing CGP transform based on this
matcher is not limited by target legality checks.
I'm not sure if the Hexagon diff means the test is no longer testing what it intended to
test, but that should be solvable in a follow-up.
Sanjay Patel [Sun, 3 Feb 2019 13:48:03 +0000 (13:48 +0000)]
[CGP] refactor optimizeCmpExpression (NFCI)
This is not truly NFC because we are bailing out without
a TLI now. That should not be a real concern though because
there should be a TLI in any real-world scenario.
That seems better than passing around a pointer and then
checking it for null-ness all over the place.
The motivation is to fix what appears to be an unintended
restriction on the uaddo transform -
hasMultipleConditionRegisters() shouldn't be reason to limit
the transform.
Craig Topper [Sun, 3 Feb 2019 07:53:39 +0000 (07:53 +0000)]
[X86] Print %st(0) as %st to match what gcc inline asm uses as the clobber name to make MS inline asm work correctly
Summary:
When calculating clobbers for MS style inline assembly we fail if the asm clobbers stack top because we print st(0) and try to pass it through the gcc register name check. This was found with when I attempted to make a emms/femms clobber all ST registers. If you use emms/femms in MS inline asm we would try to use st(0) as the clobber name but clang would think that wasn't a valid clobber name.
This also matches what objdump disassembly prints. It's also what is printed by gcc -S.
Push the insert_subvector up through the shuffle operands to help find more cross-lane shuffles.
The is exposes a couple of minor issues that will be fixed shortly:
Missed broadcast folds - we have a mixture of vzext_load lengths that need cleaning up
combine-sdiv.ll - AVX1 SimplifyDemandedVectorElts failure (hits max depth due to a couple of extra bitcasts).
We already have the getConstantOperandVal helper which returns a uint64_t, but along comes the fuzzer and inserts a i128 -1 constant or something and the whole thing asserts.......
I've updated a few obvious cases, and tried to make use of the const reference where possible, but there's more to do. A number of existing oss-fuzz tickets should be fixed if we start using APInt and perform value clamping where necessary.
Florian Hahn [Sat, 2 Feb 2019 14:42:27 +0000 (14:42 +0000)]
[LCSSA] Add expensive verification of LCSSA form for sub-loops.
This assertion makes sure all sub-loops are in LCSSA form before
bringing their parent in LCSSA form. This precondition was added to
formLCSSA in D56848.
Yonghong Song [Sat, 2 Feb 2019 05:54:59 +0000 (05:54 +0000)]
[BPF] [BTF] Process FileName with absolute path correctly
In IR, sometimes the following attributes for DIFile may be
generated:
filename: /home/yhs/test.c
directory: /tmp
The /tmp may represent the working directory of the compilation
process.
In such cases, since filename is with absolute path,
the directory should be ignored by BTF. The filename alone is
enough to get the source.
[llvm-objcopy] Temporarily limit one test to darwin
Some triples in llvm-mc appear to be unavailable on some buildbots.
To please those buildbots we temporarily limit the test to darwin
(where the required triple is guranteed to be available)
until we find the right solution.
Julian Lettner [Sat, 2 Feb 2019 02:05:16 +0000 (02:05 +0000)]
[ASan] Do not instrument other runtime functions with `__asan_handle_no_return`
Summary:
Currently, ASan inserts a call to `__asan_handle_no_return` before every
`noreturn` function call/invoke. This is unnecessary for calls to other
runtime funtions. This patch changes ASan to skip instrumentation for
functions calls marked with `!nosanitize` metadata.
Yonghong Song [Fri, 1 Feb 2019 23:23:17 +0000 (23:23 +0000)]
[BPF] [BTF] Process FileName with absolute path correctly
In IR, sometimes the following attributes for DIFile may be
generated:
filename: /home/yhs/test.c
directory: /tmp
The /tmp may represent the working directory of the compilation
process.
In such cases, since filename is with absolute path,
the directory should be ignored by BTF. The filename alone is
enough to get the source.
Philip Reames [Fri, 1 Feb 2019 22:58:52 +0000 (22:58 +0000)]
[CodeGen] Be as conservative about atomic accesses as for volatile
Background: At the moment, we record the AtomicOrdering of an access in the MMO, but also mark any atomic access as volatile in SelectionDAG. I'm working towards separating that. See https://reviews.llvm.org/D57601 for context.
Update all usages of isVolatile in lib/CodeGen to preserve behaviour once atomic MMOs stop being also volatile. This is NFC in it's current form, but is essential for correctness once we make that final change.
It useful to keep in mind that AtomicSDNode is not a parent of LoadSDNode, StoreSDNode, or LSBaseSDNode. As a result, any call to isVolatile on one of those static types doesn't need a companion isAtomic check. We should probably adjust that class hierarchy long term, but for now, that seperation is useful.
I'm deliberately being conservative about handling. I want the change to stop adding volatile to be NFC itself, and then will work through places where we can be less conservative for atomics one by one in separate changes w/tests.
[DebugInfo] Don't use realpath when looking up debug binary locations.
Summary:
Using realpath makes assumptions about build systems that do not always hold true. The debug binary referred to from the .gnu_debuglink should exist in the same directory (or in a .debug directory, etc.), but the files may only exist as symlinks to a differently named files elsewhere, and using realpath causes that lookup to fail.
This was added in r189250, and this is basically a revert + regression test case.
gn build: Create regular archives for the sanitizer runtimes.
We'll need to do this eventually if we create an installable package.
For now, this lets me use the archives to build Android, whose build
system wants to copy the archives to another location.
Philip Reames [Fri, 1 Feb 2019 19:08:59 +0000 (19:08 +0000)]
Fix a bug in the definition of isUnordered on MachineMemOperand
Background: At the moment, we record the AtomicOrdering of an access in the MMO, but also mark any atomic access as volatile in SelectionDAG. GlobalISEL keeps the two separate, but currently doesn't know how to lower an atomic G_LOAD at all. See https://reviews.llvm.org/D57601 for context.
The definition used for unordered was only checking volatility, not atomicity. As noted above, all atomic MMOs are currently also volatile, so this is a latent bug only. Copy the definition used in IR, after auditing the two (2) uses of the function to be sure the desired semantics are the same.
Matt Davis [Fri, 1 Feb 2019 18:51:10 +0000 (18:51 +0000)]
[llvm-readobj] Add a flag to dump just the section-to-segment mapping.
Summary:
The following patch introduces a new function `printSectionMapping` which is responsible for dumping just the section-to-segment mapping.
This patch also introduces a n option `-section-mapping` that outputs that mapping without the program headers.
Previously, this functionality was controlled by `printProgramHeaders`, and the output from `-program-headers` has not been changed. I am happy to change the option name, I copied the name that was displayed when outputting the mapping table.
Nico Weber [Fri, 1 Feb 2019 18:17:19 +0000 (18:17 +0000)]
gn build: Add a missing dependency from llvm/test to llvm-lit
check-llvm already listed llvm-lit as script which counts as a dep, so running
check-llvm worked fine, but `ninja -C out/gn llvm/test` didn't build llvm-lit
before if it wasn't already there.
Matt Davis [Fri, 1 Feb 2019 17:38:08 +0000 (17:38 +0000)]
[llvm-nm] Report '.comment' ELF sections as 'n' instead of '?'
Summary:
The previous implementation reported `.comment` sections as '?'
GNU uses 'n' which means "The symbol is a debugging symbol." `.note` sections are represented as 'n' too.
The test related to this change was updated to CHECK-NEXT to ensure
order and that we did not miss any symbols in the dump.
[llvm-objcopy][NFC] More error propagation (executeObjcopyOnArchive)
Summary:
Replace some reportError() calls with error propagation that was missed from rL352625.
Note this also adds an error check during Archive iteration that was being hidden by a different error check before:
```
for (const Archive::Child &Child : Ar.children(Err)) {
Expected<std::unique_ptr<Binary>> ChildOrErr = Child.getAsBinary();
if (!ChildOrErr)
// This aborts, so Err is never checked
reportError(Ar.getFileName(), ChildOrErr.takeError());
```
Err is being checked after the loop, so during happy runs, everything is fine. But when reportError is changed to return the error instead of aborting, the fact that Err is never checked is now noticed in tests that trigger an error during the loop.
Tim Corringham [Fri, 1 Feb 2019 16:51:09 +0000 (16:51 +0000)]
[AMDGPU] Fix for vector element insertion
Summary:
Incorrect code was generated when lowering insertelement operations
for vectors with 8 or 16 bit elements. The value being inserted was
not adjusted for the position of the element within the 32 bit word
and so only the low element within each 32 bit word could receive
the intended value.
Fixed by simply replicating the value to each element of a
congruent vector before the mask and or operation used to
update the intended element.
A number of affected LIT tests have been updated appropriately.
Sanjay Patel [Fri, 1 Feb 2019 16:06:53 +0000 (16:06 +0000)]
[SDAG] improve variable names; NFC
The version of FoldConstantArithmetic() that takes arbitrary nodes
was confusingly naming those nodes as constants when they might
not be; also "Cst" reads like "Cast".
Simon Pilgrim [Fri, 1 Feb 2019 16:02:12 +0000 (16:02 +0000)]
[X86][SSE] Use PSLLDQ/PSRLDQ to mask out zeroable ends of a shuffle
As suggested on PR40318, this patch uses PSLLDQ/PSRLDQ to lower shuffles to zero out the ends of a vector, leaving a sequential inner section.
For pre-SSSE3 we do this for shuffles with zeros at either end (requiring up to 3 shifts), but once PSHUFB is available I've limited this to shuffles with a single zeroable end (2 shifts).
Sanjay Patel [Fri, 1 Feb 2019 15:35:12 +0000 (15:35 +0000)]
[TargetLowering] try harder to determine undef elements of vector binops
This might be the start of tracking all vector element constants generally if we take it to its
logical conclusion, but let's stop here and make sure this is correct/beneficial so far.
The affected tests require a convoluted path before they get simplified currently because we
don't call SimplifyDemandedVectorElts() from binops directly and don't modify the binop operands
directly in SimplifyDemandedVectorElts().
That's why the tests all have a trailing shuffle to induce a chain reaction of transforms. So
something like this is happening:
1. Improve the knowledge of undefs in the binop via a SimplifyDemandedVectorElts() call that
originates from a shuffle.
2. Transfer that undef knowledge back to the shuffle mask user as more undef lanes.
3. Combine the modified shuffle by calling SimplifyDemandedVectorElts() again.
4. Translate the improved shuffle mask as undemanded lanes of build vector constants causing
those to become full undef constants.
5. Simplify the binop now that it has a full undef operand.
As we can see from the unchanged 'and' and 'or' tests, tracking undefs alone isn't a full solution.
We would need to track zero and all-ones constants to improve those opcodes. We'd probably need to
track NaN for FP ops too (assuming we don't have fast-math-flags set).
Sanjay Patel [Fri, 1 Feb 2019 14:37:49 +0000 (14:37 +0000)]
[InstCombine] reduce duplicate code; NFC
An unused variable problem was introduced with rL352870
and stubbed out with rL352871, but we can make a better
fix by actually using the local variable in code rather
than just the assert.
Sanjay Patel [Fri, 1 Feb 2019 14:14:47 +0000 (14:14 +0000)]
[InstCombine] try to reduce x86 addcarry to generic uaddo intrinsic
If we can reduce the x86-specific intrinsic to the generic op, it allows existing
simplifications and value tracking folds. AFAICT, this always results in identical
x86 codegen in the non-reduced case...which should be true because we semi-generically
(too aggressively IMO) convert to llvm.uadd.with.overflow in CGP, so the DAG/isel must
already combine/lower this intrinsic as expected.
This isn't quite what was requested in:
https://bugs.llvm.org/show_bug.cgi?id=40486
...but we want to have these kinds of folds early for efficiency and to enable greater
simplifications. For the case in the bug report where we have:
_addcarry_u64(0, ahi, 0, &ahi)
...this gets completely simplified away in IR.
projects / llvm / log