- Feb 03, 2018
-
-
David Green authored
This, in instcombine, allows conversions to i8/i16/i32 (very common cases) even if the resulting type is not legal according to the data layout. This can often open up extra combine opportunities. Differential Revision: https://reviews.llvm.org/D42424 llvm-svn: 324174
-
Alex Bradbury authored
From the discussion in D41835 it looks possible the change will be backed out, but for now let's fix the RISCV tests. llvm-svn: 324172
-
- Feb 02, 2018
-
-
Sanjay Patel authored
Without extra instructions and uses, swapMayExposeCSEOpportunities() would change the icmp (as seen in the check lines), so we were not actually testing patterns that should be handled by D41480. llvm-svn: 324143
-
Craig Topper authored
[X86] Add avx512 command line to ptest.ll to demonstrate that 512-bit vectors are not handled by LowerVectorAllZeroTest. llvm-svn: 324130
-
Craig Topper authored
Partially revert r324124 [X86] Add tests for missed opportunities to use ptest for all ones comparison. Turns out I misunderstood the flag behavior of PTEST because I read the documentation for KORTEST which is different than PTEST/KTEST and made a bad assumption. Keep the test rename though cause that's useful. llvm-svn: 324129
-
Craig Topper authored
Also rename the test from pr12312.ll to ptest.ll so its more recognizable. llvm-svn: 324124
-
Sanjay Patel authored
llvm-svn: 324109
-
Craig Topper authored
[X86] Remove checks for FeatureAVX512 from the X86 assembly parser. Remove mcpu/mattr from assembly test command lines. Summary: We should always be able to accept AVX512 registers and instructions in llvm-mc. The only subtarget mode that should be checked is 16-bit vs 32-bit vs 64-bit mode. I've also removed all the mattr/mcpu lines from test RUN lines to be consistent with this. Most were due to AVX512, but a few were for other features. Fixes PR36202 Reviewers: RKSimon, echristo, bkramer Reviewed By: echristo Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D42824 llvm-svn: 324106
-
Yaxun Liu authored
This requires corresponding clang change. Differential Revision: https://reviews.llvm.org/D40955 llvm-svn: 324101
-
Clement Courbet authored
See https://reviews.llvm.org/D42793#996098 for context. llvm-svn: 324099
-
Simon Pilgrim authored
llvm-svn: 324094
-
Ivan A. Kosarev authored
This patch implements analysis for new-format TBAA access tags with aggregate types as their final access types. Differential Revision: https://reviews.llvm.org/D41501 llvm-svn: 324092
-
James Henderson authored
Differential Revision: https://reviews.llvm.org/D42481 llvm-svn: 324078
-
George Rimar authored
This fixes PR36187. Patch teaches ThinLTO to drop non-prevailing variables, just like we recently did for functions (in r323633). Differential revision: https://reviews.llvm.org/D42798 llvm-svn: 324075
-
Sjoerd Meijer authored
llvm-svn: 324074
-
Mikael Holmen authored
Summary: When creating the debug fragments for a SRA'd variable, use the types' allocation sizes. This fixes issues where the pass would emit too small fragments, placed at the wrong offset, for padded types. An example of this is long double on x86. The type is represented using x86_fp80, which is 10 bytes, but the value is aligned to 12/16 bytes. The padding is included in the type's DW_AT_byte_size attribute; therefore, the fragments should also include that. Newer GCC releases (I tested 7.2.0) emit 12/16-byte pieces for long double. Earlier releases, e.g. GCC 5.5.0, behaved as LLVM did, i.e. by emitting a 10-byte piece, followed by an empty 2/6-byte piece for the padding. Failing to cover all `DW_AT_byte_size' bytes of a value with non-empty pieces results in the value being printed as <optimized out> by GDB. Patch by: David Stenberg Reviewers: aprantl, JDevlieghere Reviewed By: aprantl, JDevlieghere Subscribers: llvm-commits Tags: #debug-info Differential Revision: https://reviews.llvm.org/D42807 llvm-svn: 324066
-
Jonas Paulsson authored
When handling vectors with non byte-sized elements, reverse the order of the elements in the built integer if the target is Big-Endian. SystemZ tests updated. Review: Eli Friedman, Ulrich Weigand. https://reviews.llvm.org/D42786 llvm-svn: 324063
-
Jonas Paulsson authored
test/CodeGen/SystemZ/vec-trunc-to-i1.ll was marked as a temporary FAIL when it was previously updated when it needed one more COPY. This was however wrong, since the loop body had been reduced significantly, and it was actually an improvement. Review: Ulrich Weigand. llvm-svn: 324060
-
Shiva Chen authored
llvm-objdump could get C feature by ELF::EF_RISCV_RVC e_flag, so then we don't have to add -mattr=+c on the command line. Differential Revision: https://reviews.llvm.org/D42629 llvm-svn: 324058
-
Craig Topper authored
[X86] Legalize (v64i1 (bitcast (i64 X))) on 32-bit targets by extracting 32-bit halves from i32, bitcasting each to v32i1, and concatenating. This prevents the scalarization that would otherwise occur. llvm-svn: 324057
-
Craig Topper authored
[X86] Legalize (i64 (bitcast (v64i1 X))) on 32-bit targets by extracting to v32i1 and bitcasting to i32. This saves a trip through memory and seems to open up other combining opportunities. llvm-svn: 324056
-
Shiva Chen authored
Differential Revision: https://reviews.llvm.org/D42782 llvm-svn: 324055
-
Shiva Chen authored
To avoid trigger "No default SetCC type for vectors!" Assertion Differential Revision: https://reviews.llvm.org/D42675 llvm-svn: 324054
-
Amara Emerson authored
My rebase had missed the new $ sigil we're using. llvm-svn: 324051
-
Amara Emerson authored
This fixes a crash where the user is a COPY, which deliberately does not constrain its source operands, resulting in a vreg without a reg class escaping selection. Differential Revision: https://reviews.llvm.org/D42697 llvm-svn: 324047
-
Matthias Braun authored
Example situation: ``` BB0: %0 = ... use %0 ; ... condjump BB1 jmp BB2 BB1: %0 = ... ; rematerialized def from above (from earlier split step) jmp BB2 BB2: ; ... use %0 ``` %0 will have a live interval with 3 value numbers (for the BB0, BB1 and BB2 parts). Now SplitKit tries and succeeds in rematerializing the value number in BB2 (This only works because it is a secondary split so SplitKit is can trace this back to a single original def). We need to recompute all live ranges affected by a value number that we rematerialize. The case that we missed before is that when the value that is rematerialized is at a join (Phi VNI) then we also have to recompute liveness for the predecessor VNIs. rdar://35699130 Differential Revision: https://reviews.llvm.org/D42667 llvm-svn: 324039
-
Vlad Tsyrklevich authored
Summary: This update now allows users to specify `--blame-context` and `--blame-context-all` to print source file blame information for the source of the blame. Also updates the inline printing to correctly identify the top of the inlining stack for blame information. Patch by Mitch Phillips! Reviewers: vlad.tsyrklevich Subscribers: llvm-commits, kcc, pcc Differential Revision: https://reviews.llvm.org/D40111 llvm-svn: 324035
-
- Feb 01, 2018
-
-
Simon Pilgrim authored
llvm-svn: 324024
-
Simon Pilgrim authored
llvm-svn: 324017
-
Simon Pilgrim authored
llvm-svn: 324015
-
Sanjay Patel authored
This is the enhancement suggested in D42536 to fix a shortcoming in regular InstCombine's canEvaluate* functionality. When we have multiple uses of a value, but they're all in one instruction, we can allow that expression to be narrowed or widened for the same cost as a single-use value. AFAICT, this can only matter for multiply: sub/and/or/xor/select would be simplified away if the operands are the same value; add becomes shl; shifts with a variable shift amount aren't handled. Differential Revision: https://reviews.llvm.org/D42739 llvm-svn: 324014
-
Nemanja Ivanovic authored
This is a rather non-controversial change. We were missing these instructions from the list of instructions that are lane-sensitive. These two put the result into lane 0 (BE) or 3 (LE) regardless of the input. This patch fixes PR36068. llvm-svn: 324005
-
Craig Topper authored
[DAGCombiner] When folding (insert_subvector undef, (bitcast (extract_subvector N1, Idx)), Idx) -> (bitcast N1) make sure that N1 has the same total size as the original output We were only checking the element count, but not the total width. This could cause illegal bitcasts to be created if for example the output was 512-bits, but N1 is 256 bits, and the extraction size was 128-bits. Fixes PR36199 Differential Revision: https://reviews.llvm.org/D42809 llvm-svn: 324002
-
Amara Emerson authored
Until we support extending loads properly we're going to fall back for these. We already handle stores in the same way, so this is just being consistent. llvm-svn: 324001
-
Brock Wyma authored
Increment the field list member count for base classes and virtual base classes. Differential Revision: https://reviews.llvm.org/D41874 llvm-svn: 324000
-
Geoff Berry authored
Summary: This change extends MachineCopyPropagation to do COPY source forwarding and adds an additional run of the pass to the default pass pipeline just after register allocation. This version of this patch uses the newly added MachineOperand::isRenamable bit to avoid forwarding registers is such a way as to violate constraints that aren't captured in the Machine IR (e.g. ABI or ISA constraints). This change is a continuation of the work started in D30751. Reviewers: qcolombet, javed.absar, MatzeB, jonpa, tstellar Subscribers: tpr, mgorny, mcrosier, nhaehnle, nemanjai, jyknight, hfinkel, arsenm, inouehrs, eraman, sdardis, guyblank, fedor.sergeev, aheejin, dschuff, jfb, myatsina, llvm-commits Differential Revision: https://reviews.llvm.org/D41835 llvm-svn: 323991
-
Changpeng Fang authored
AMDGPU/SI: Adjust the encoding family for D16 buffer instructions when the target has UnpackedD16VMem feature. Reviewers: Matt and Brian Differential Revision: https://reviews.llvm.org/D42548 llvm-svn: 323988
-
Simon Pilgrim authored
This allows us to use PSHUFB for v8i16/v4i32 and VPERMD/PERMPS for v4i64/v4f64 variable shuffles. Differential Revision: https://reviews.llvm.org/D42487 llvm-svn: 323987
-
Sanjay Patel authored
As noted in D42323, we're not checking for denorms as we should. llvm-svn: 323985
-
Sanjay Patel authored
llvm-svn: 323984
-