[X86] Change vXi1 extract_vector_elt lowering to be legal if the index is 0. Add DAG combine to turn scalar_to_vector+extract_vector_elt into extract_subvector.

Comments

[X86] Change vXi1 extract_vector_elt lowering to be legal if the index is 0. Add DAG combine to turn scalar_to_vector+extract_vector_elt into extract_subvector.
We were lowering the last step extract_vector_elt to a bitcast+truncate. Change it to use an extract_vector_elt of index 0 instead. Add isel patterns to do the equivalent of what the bitcast would have done. Plus an isel pattern for an any_extend+extract to prevent some regressions.
Finally add a DAG combine to turn v1i1 scalar_to_vector+extract_vector_elt of 0 into an extract_subvector.
This fixes some of the regressions from D350800.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@350918 91177308-0d34-0410-b5e6-96231b3b80d8

Comments

[llvm-objdump][MachO] Disable some invalid input tests
It causes some (but not all) bots to fail. I'll look into it tomorrow
morning. Remove the tests for now to make the bots green.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@350908 91177308-0d34-0410-b5e6-96231b3b80d8

Changed files

test/tools/llvm-objdump/invalid-input.test

[WebAssembly] Fix stack pointer store check in RegStackify

Comments

[WebAssembly] Fix stack pointer store check in RegStackify
Summary:
We now use __stack_pointer global and global.get/global.set instruction.
This fixes the checking routine for stack_pointer writes accordingly.
This also fixes the existing __stack_pointer test in reg-stackify.ll:
That test used to pass not because of __stack_pointer clashes but
because the function `stackpointer_callee` was not marked as `readnone`,
so it was assumed to possibly write to memory arbitraily, and
`global.set` instruction was marked as `mayStore` in the .td definition,
so they were identified as intervening writes. After we added `readnone`
to its attribute, this test fails without this patch.
Reviewers: dschuff, sunfish
Subscribers: jgravelle-google, sbc100, llvm-commits
Differential Revision: https://reviews.llvm.org/D56094
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@350906 91177308-0d34-0410-b5e6-96231b3b80d8

[WebAssembly] Add unimplemented-simd128 subtarget feature

Comments

[WebAssembly] Add unimplemented-simd128 subtarget feature
Summary:
This is a third attempt, but this time we have vetted it on Windows
first. The previous errors were due to an uninitialized class member.
Reviewers: aheejin
Subscribers: dschuff, sbc100, jgravelle-google, sunfish, jfb, llvm-commits
Differential Revision: https://reviews.llvm.org/D56560
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@350901 91177308-0d34-0410-b5e6-96231b3b80d8

[MemorySSA] Disable checkClobberSanity for SkipSelfWalker.

Comments

[MemorySSA] Disable checkClobberSanity for SkipSelfWalker.
Sanity will fail for this, since we're exploring getting a clobber
further than the sanity check expects.
Ideally we need to teach the sanity check to differentiate between the
two walkers based on the SkipSelf bool in the query.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@350895 91177308-0d34-0410-b5e6-96231b3b80d8

[GVN] Update BlockRPONumber prior to use.

Comments

[GVN] Update BlockRPONumber prior to use.
Summary:
The original patch addressed the use of BlockRPONumber by forcing a sequence point when accessing that map in a conditional. In short we found cases where that map was being accessed with blocks that had not yet been added to that structure. For context, I've kept the wall of text below, to what we are trying to fix, by always ensuring a updated BlockRPONumber.
== Backstory ==
I was investigating an ICE (segfault accessing a DenseMap item). This failure happened non-deterministically, with no apparent reason and only on a Windows build of LLVM (from October 2018).
After looking into the crashes (multiple core files) and running DynamoRio, the cores and DynamoRio (DR) log pointed to the same code in `GVN::performScalarPRE()`. The values in the map are unsigned integers, the keys are `llvm::BasicBlock*`. Our test case that triggered this warning and periodic crash is rather involved. But the problematic line looks to be:
GVN.cpp: Line 2197
```
if (BlockRPONumber[P] >= BlockRPONumber[CurrentBlock] &&
```
To test things out, I cooked up a patch that accessed the items in the map outside of the condition, by forcing a sequence point between accesses. DynamoRio stopped warning of the issue, and the test didn't seem to crash after 1000+ runs.
My investigation was on an older version of LLVM, (source from October this year). What it looks like was occurring is the following, and the assembly from the latest pull of llvm in December seems to confirm this might still be an issue; however, I have not witnessed the crash on more recent builds. Of course the asm in question is generated from the host compiler on that Windows box (not clang), but it hints that we might want to consider how we access the BlockRPONumber map in this conditional (line 2197, listed above). In any case, I don't think the host compiler is wrong, rather I think it is pointing out a possibly latent bug in llvm.
1) There is no sequence point for the `>=` operation.
2) A call to a `DenseMapBase::operator[]` can have the side effect of the map reallocating a larger store (more Buckets, via a call to `DenseMap::grow`).
3) It seems perfectly legal for a host compiler to generate assembly that stores the result of a call to `operator[]` on the stack (that's what my host compile of GVN.cpp is doing) . A second call to `operator[]` //might// encourage the map to 'grow' thus making any pointers to the map's store invalid. The `>=` compares the first and second values. If the first happens to be a pointer produced from operator[], it could be invalid when dereferenced at the time of comparison.
The assembly generated from the Window's host compiler does show the result of the first access to the map via `operator[]` produces a pointer to an unsigned int. And that pointer is being stored on the stack. If a second call to the map (which does occur) causes the map to grow, that address (on the stack) is now invalid.
Reviewers: t.p.northover, efriedma
Reviewed By: efriedma
Subscribers: efriedma, llvm-commits
Differential Revision: https://reviews.llvm.org/D55974
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@350880 91177308-0d34-0410-b5e6-96231b3b80d8

Use MemorySSA in LICM to do sinking and hoisting.

Comments

Use MemorySSA in LICM to do sinking and hoisting.
Summary:
Step 2 in using MemorySSA in LICM:
Use MemorySSA in LICM to do sinking and hoisting, all under "EnableMSSALoopDependency" flag.
Promotion is disabled.
Enable flag in LICM sink/hoist tests to test correctness of this change. Moved one test which
relied on promotion, in order to test all sinking tests.
Reviewers: sanjoy, davide, gberry, george.burgess.iv
Subscribers: llvm-commits, Prazek
Differential Revision: https://reviews.llvm.org/D40375
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@350879 91177308-0d34-0410-b5e6-96231b3b80d8

[X86] Simplify the BRCOND handling for FCMP_UNE.

Comments

[X86] Simplify the BRCOND handling for FCMP_UNE.
Despite what the comment says, FCMP_UNE would be an OR not an AND. In the lowering code the first branch created still goes to the original destination. The second branch was exchanged to go to where the subsequent unconditional branch went. This is different than what we do for FCMP_OEQ where both branches that we create go to the original unconditional branch.
As far as I can tell, I think this means we don't need to exchange the branch target with the unconditional branch for FCMP_UNE at all.
Differential Revision: https://reviews.llvm.org/D56309
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@350873 91177308-0d34-0410-b5e6-96231b3b80d8

Comments

[llvm-objdump][MachO] Fix test to work on Windows
This fails in http://lab.llvm.org:8011/builders/clang-x64-windows-msvc/builds/3208/steps/stage%201%20check/logs/stdio.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@350871 91177308-0d34-0410-b5e6-96231b3b80d8

[FileCheck] Don't propagate `FILECHECK_DUMP_INPUT_ON_FAILURE` and

Comments

[FileCheck] Don't propagate `FILECHECK_DUMP_INPUT_ON_FAILURE` and
`FILECHECK_OPTS` into environment for FileCheck tests.
Summary:
This fixes the following FileCheck tests:
* FileCheck/dump-input-enable.txt
* FileCheck/match-full-lines.txt
when `FILECHECK_DUMP_INPUT_ON_FAILURE` is set in the environment.
By default llvm-lit propagates `FILECHECK_DUMP_INPUT_ON_FAILURE` and
`FILECHECK_OPTS` from llvm-lit's environment into the test environment.
Unfortunately this can break FileCheck's tests because they expect that
these environment variables not to be set.
rdar://problem/47176262
Reviewers: jdenny, probinson, george.karpenkov
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D56541
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@350850 91177308-0d34-0410-b5e6-96231b3b80d8

Comments

[llvm-objdump][MachO] Correctly handle the llvm::Error when -dsym has errors
In an assert build, the Error gets destroyed and we get "Program aborted
due to an unhandled Error:".
In release, we get an empty message.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@350848 91177308-0d34-0410-b5e6-96231b3b80d8