summaryrefslogtreecommitdiffstats
path: root/llvm/test/CodeGen
Commit message (Collapse)AuthorAgeFilesLines
* revert r328921 - [DAGCombine] (float)((int) f) --> ftrunc (PR36617)Sanjay Patel2018-04-128-83/+330
| | | | | | | This change is exposing UB in source code - as was warned/predicted. :) See D44909 for discussion. Reverting while we figure out how to fix things. llvm-svn: 329920
* [RISCV] Change function alignment to 4 bytes, and 2 bytes for RVCShiva Chen2018-04-121-0/+13
| | | | | | | | | | | | | | | | | | Summary: According RISC-V ELF psABI specification, base RV32 and RV64 ISAs only allow 32-bit instruction alignment, but instruction allow to be aligned to 16-bit boundaries for C-extension. So we just align to 4 bytes and 2 bytes for C-extension is enough. Reviewers: asb, apazos Differential Revision: https://reviews.llvm.org/D45560 Patch by Kito Cheng. llvm-svn: 329899
* [MIPS GlobalISel] minor update to MIR tests added in r329819Petar Jovanovic2018-04-123-12/+0
| | | | | | | | Remove 'registers' section, as suggested (D. Sanders) at code review https://reviews.llvm.org/D44304 llvm-svn: 329888
* [NFC] fix trivial typos in documents and commentsHiroshi Inoue2018-04-121-1/+1
| | | | | | "is is" -> "is", "if if" -> "if", "or or" -> "or" llvm-svn: 329878
* [RISCV] Codegen support for RV32D floating point comparison operationsAlex Bradbury2018-04-124-0/+1327
| | | | | | | | Also add double-prevoius-failure.ll which captures a test case that at one point triggered a compiler crash, while developing calling convention support for f64 on RV32D with soft-float ABI. llvm-svn: 329877
* [RISCV] Codegen support for RV32D floating point conversion operationsAlex Bradbury2018-04-122-0/+106
| | | | | | | This also includes support and a test for truncating stores, which are now possible thanks to the fpround pattern. llvm-svn: 329876
* [RISCV] Add codegen support for RV32D floating point arithmetic operationsAlex Bradbury2018-04-121-0/+256
| | | | llvm-svn: 329874
* [RISCV] Add tests missed in r329871Alex Bradbury2018-04-126-0/+464
| | | | llvm-svn: 329872
* [PowerPC] Fix condition for 64-bit rotate when replacing r+r instr with r+iNemanja Ivanovic2018-04-111-0/+64
| | | | | | | | | | This patch fixes https://bugs.llvm.org/show_bug.cgi?id=37039 The condition only covers one of the two 64-bit rotate instructions. This just adds the second (RLDICLo). Patch by Josh Stone. llvm-svn: 329852
* Attempting to work around a non-determinism issue.Puyan Lotfi2018-04-111-2/+0
| | | | | | | The main thing that matters with this test is that the COPYs are moved together not where the REG_SEQUENCES are. llvm-svn: 329850
* [X86] Describe wbnoinvd instructionGabor Buella2018-04-111-0/+18
| | | | | | | | | | | | | | | Similar to the wbinvd instruction, except this one does not invalidate caches. Ring 0 only. The encoding matches a wbinvd instruction with an F3 prefix. Reviewers: craig.topper, zvi, ashlykov Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D43816 llvm-svn: 329847
* [X86][Atom] Convert Atom scheduler model to SchedRW (PR32431)Simon Pilgrim2018-04-1111-159/+172
| | | | | | | | | | | | | | | | Atom is the only x86 target that still uses schedule itineraries, if we can remove this then we can begin the work on removing x86 itineraries. I've also found that it will help with PR36550. I've focussed on matching the existing model as closely as possible (relying on the schedule tests), PR36895 indicated a lot of these were incorrect but we can just as easily fix these after this patch as before. Hopefully we can get llvm-exegesis to help here, There are a few instructions that rely on itinerary scheduling (mainly push/pop/return) of multiple resource stages, but I don't think any of these are show stoppers. There are also a few codegen changes that seem related to the post-ra scheduler acting a little differently, I haven't tracked these down but they don't seem critical. NOTE: I don't have access to any Atom hardware, so this hasn't been tested in the wild. Differential Revision: https://reviews.llvm.org/D45486 llvm-svn: 329837
* [AMDGPU] Ensure there are enough registers for wave dispatchTim Renouf2018-04-111-0/+18
| | | | | | | | | | | | | | | | | Summary: This fixes the number of SGPRs and VGPRs in the *_RSRC1 register to allow for registers set up in wave dispatch, even if those registers are not used in the shader. Re-landed after noticing that the buildbot failure from 329808 seemed to be unrelated. Subscribers: arsenm, kzhuravl, wdng, nhaehnle, yaxunl, dstuttard, t-tye, llvm-commits Differential Revision: https://reviews.llvm.org/D45503 Change-Id: I6575f0e0d2a528d1319d0b289f0ebe4510fa5771 llvm-svn: 329826
* [FastISel] Disable local value sinking by defaultReid Kleckner2018-04-1126-64/+64
| | | | | | | | | | | | | | | | | | This is causing compilation timeouts on code with long sequences of local values and calls (i.e. foo(1); foo(2); foo(3); ...). It turns out that code coverage instrumentation is a great way to create sequences like this, which how our users ran into the issue in practice. Intel has a tool that detects these kinds of non-linear compile time issues, and Andy Kaylor reported it as PR37010. The current sinking code scans the whole basic block once per local value sink, which happens before emitting each call. In theory, local values should only be introduced to be used by instructions between the current flush point and the last flush point, so we should only need to scan those instructions. llvm-svn: 329822
* [DWARFv5] Fuss with asm syntax for conveying MD5 checksum.Paul Robinson2018-04-111-3/+3
| | | | | | | | | | Previously the MD5 option of the .file directive provided the checksum as a quoted hex string; now it's a normal hex number with 0x prefix, same as the .octa directive accepts. Differential Revision: https://reviews.llvm.org/D45459 llvm-svn: 329820
* [MIPS GlobalISel] Select add i32, i32Petar Jovanovic2018-04-115-0/+131
| | | | | | | | | | | | | Add the minimal support necessary to lower a function that returns the sum of two i32 values. Support argument/return lowering of i32 values through registers only. Add tablegen for regbankselect and instructionselect. Patch by Petar Avramovic. Differential Revision: https://reviews.llvm.org/D44304 llvm-svn: 329819
* [AMDGPU] Fix lowering enqueue_kernelYaxun Liu2018-04-111-4/+17
| | | | | | | | | | | | | | | | | | Two issues were fixed: runtime has difficulty to allocate memory for an external symbol of a kernel and set the address of the external symbol, therefore make the runtime handle of an enqueued kernel an ordinary global variable. Runtime only needs to store the address of the loaded kernel to the handle and has verified that this approach works. handle the situation where __enqueue_kernel* gets inlined therefore the enqueued kernel may be used through a constant expr instead of an instruction. Differential Revision: https://reviews.llvm.org/D45187 llvm-svn: 329815
* Revert "[AMDGPU] Ensure there are enough registers for wave dispatch"Tim Renouf2018-04-111-18/+0
| | | | | | | | | This reverts 329808. That change caused a report of a failure in test/CodeGen/MIR/AMDGPU/mir-canon-multi.mir that I didn't see. I suspect it is an expensive-check-only error. Change-Id: I8133f26f15e7d5ec2b09c687c12cd70e918461b0 llvm-svn: 329811
* [AMDGPU] Ensure there are enough registers for wave dispatchTim Renouf2018-04-111-0/+18
| | | | | | | | | | | | | | Summary: This fixes the number of SGPRs and VGPRs in the *_RSRC1 register to allow for registers set up in wave dispatch, even if those registers are not used in the shader. Subscribers: arsenm, kzhuravl, wdng, nhaehnle, yaxunl, dstuttard, t-tye, llvm-commits Differential Revision: https://reviews.llvm.org/D45503 Change-Id: I6575f0e0d2a528d1319d0b289f0ebe4510fa5771 llvm-svn: 329808
* [X86] Add variable shuffle schedule classesSimon Pilgrim2018-04-114-62/+62
| | | | | | | | | | | | | | Split variable index shuffles from immediate index shuffles WriteFVarShuffle - variable 'in-lane' shuffles (VPERMILPS/VPERMIL2PS etc.) WriteVarShuffle - variable 'in-lane' shuffles (PSHUFB/VPPERM etc.) WriteFVarShuffle256 - variable 'cross-lane' shuffles (VPERMPS etc.) WriteVarShuffle256 - variable 'cross-lane' shuffles (VPERMD etc.) Differential Revision: https://reviews.llvm.org/D45404 llvm-svn: 329806
* [AArch64] Add test case for r329797Francis Visoiu Mistrih2018-04-111-0/+17
| | | | | | Forgot to add a test case in the previous commit. llvm-svn: 329805
* [X86][SSE] Tweak cmpps schedule test so that it works properly with just sse1Simon Pilgrim2018-04-111-4/+5
| | | | | | movhps/movlps test are still broken so we can't disable sse2 yet llvm-svn: 329802
* [ARM] FP16 VSEL codegenSjoerd Meijer2018-04-111-12/+142
| | | | | | | | | | | | | This is a follow up of rL327695 to instruction select more variants of VSELGT and VSELGE, for which it is necessary to custom lower SELECT. More work is required in this area, which will be addressed soon: - more variants need to be regression tested, but this depends on the next point. - first LowerConstantFP need to be adjusted for fp16 values. Differential Revision: https://reviews.llvm.org/D45205 llvm-svn: 329788
* [X86] Remove 128/256-bit masked pmaddubsw and pmaddwd intrinsics. Replace ↵Craig Topper2018-04-114-46/+171
| | | | | | | | 512-bit masked intrinsic with unmasked intrinsic and a select. The 128/256-bit versions were no longer used by clang. It uses the legacy SSE/AVX2 version and a select. The 512-bit was changed to the same for consistency. llvm-svn: 329774
* [X86] In X86FlagsCopyLowering, when rewriting a memory setcc we need to emit ↵Craig Topper2018-04-111-2/+1
| | | | | | | | | | an explicit MOV8mr instruction. Previously the code only knew how to handle setcc to a register. This should fix a crash in the chromium build. llvm-svn: 329771
* [X86] Switch a test from grep to FileCheck. NFCCraig Topper2018-04-111-1/+11
| | | | llvm-svn: 329769
* Simplification of libcall like printf->puts must check for RtLibUseGOT metadata.Sriraman Tallam2018-04-101-0/+19
| | | | | | | | | | With -fno-plt, for example, calls to printf when getting converted to puts still use the PLT. This patch checks for the metadata "RtLibUseGOT" and annotates the declaration with the right attributes. Differential Revision: https://reviews.llvm.org/D45180 llvm-svn: 329768
* GOTPCREL references must always use RIP.Sriraman Tallam2018-04-101-0/+6
| | | | | | | | With -fno-plt, global value references can use GOTPCREL and RIP must be used. Differential Revision: https://reviews.llvm.org/D45460 llvm-svn: 329765
* AMDGPU: enable 128-bit for local addr space under an optionMarek Olsak2018-04-106-14/+14
| | | | | | | | | | | | | | | | | | | Author: Samuel Pitoiset ds_read_b128 and ds_write_b128 have been recently enabled under the amdgpu-ds128 option because the performance benefit is unclear. Though, using 128-bit loads/stores for the local address space appears to introduce regressions in tessellation shaders. Not sure what is broken, but as ds_read_b128/ds_write_b128 are not enabled by default, just introduce a global option and enable 128-bit only if requested (until it's fixed/used correctly). v2: - fix regressions in merge-stores.ll and multiple_tails.ll Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105464 llvm-svn: 329764
* Disable flaky tests till they get fixed.Galina Kistanova2018-04-102-1/+2
| | | | llvm-svn: 329763
* [AArch64][Falkor] Fix bug in Falkor HWPF collision avoidance pass.Geoff Berry2018-04-101-0/+25
| | | | | | | | | | | | | | | | Summary: When inserting MOVs to avoid Falkor HWPF collisions, the non-base register operand of load instructions (e.g. a register offset) was not being considered live, so it could potentially have been used as a scratch register, clobbering the actual offset value. Reviewers: mcrosier Subscribers: rengolin, javed.absar, kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D45502 llvm-svn: 329761
* [MachO] Emit Weak ReadOnlyWithRel to ConstDataSectionSteven Wu2018-04-101-0/+5
| | | | | | | | | | | | | | | | | Summary: Darwin dynamic linker can handle weak symbols in ConstDataSection. ReadonReadOnlyWithRel symbols should be emitted in ConstDataSection instead of normal DataSection. rdar://problem/39298457 Reviewers: dexonsmith, kledzik Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D45472 llvm-svn: 329752
* [AArch64] Fix isel failure when BUILD_PAIR nodes are left over.Amara Emerson2018-04-101-0/+13
| | | | | | rdar://39175175 llvm-svn: 329743
* [X86] Split up -march=icelake to -client & -serverGabor Buella2018-04-105-5/+10
| | | | | | | | | | Reviewers: craig.topper, zvi, echristo Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D45055 llvm-svn: 329742
* [CodeGen] Fix printing bundles in MIR outputKrzysztof Parzyszek2018-04-101-2/+1
| | | | | | | | | | | | | | | | Delay printing the newline until after the opening bracket was printed, e.g. BUNDLE implicit-def $r1, implicit-def $r21, implicit $r1 { renamable $r1 = S2_asr_i_r renamable $r1, 1 renamable $r21 = A2_tfrsi 0 } instead of BUNDLE implicit-def $r1, implicit-def $r21, implicit $r1 { renamable $r1 = S2_asr_i_r renamable $r1, 1 renamable $r21 = A2_tfrsi 0 } llvm-svn: 329719
* Revert r329611, "AArch64: Allow offsets to be folded into addresses with ELF."Peter Collingbourne2018-04-1011-191/+127
| | | | | | Caused a build failure in check-tsan. llvm-svn: 329718
* [AArch64] Use FP to access the emergency spill slotFrancis Visoiu Mistrih2018-04-102-2/+23
| | | | | | | | | | | | | | | | | | | | | In the presence of variable-sized stack objects, we always picked the base pointer when resolving frame indices if it was available. This makes us hit an assert where we can't reach the emergency spill slot if it's too far away from the base pointer. Since on AArch64 we decide to place the emergency spill slot at the top of the frame, it makes more sense to use FP to access it. The changes here don't affect only emergency spill slots but all the frame indices. The goal here is to try to choose between FP, BP and SP so that we minimize the offset and avoid scavenging, or worse, asserting when trying to access a slot allocated by the scavenger. Previously discussed here: https://reviews.llvm.org/D40876. Differential Revision: https://reviews.llvm.org/D45358 llvm-svn: 329691
* [AMDGPU] For OS type AMDPAL, fixed scratch on compute shaderTim Renouf2018-04-101-0/+29
| | | | | | | | | | | | | | | | | | | | | Summary: For OS type AMDPAL, the scratch descriptor is loaded from offset 0 of the GIT, whose 32 bit pointer is in s0 (s8 for gfx9 merged shaders). This commit fixes that to use offset 0x10 instead of offset 0 for a compute shader, per the PAL ABI spec. V2: Ensure s0 (s8 for gfx9 merged shader) is marked live-in when loading scratch descriptor from GIT. Reviewers: kzhuravl, nhaehnle, timcorringham Subscribers: kzhuravl, wdng, yaxunl, t-tye, llvm-commits, dstuttard, nhaehnle, arsenm Differential Revision: https://reviews.llvm.org/D44468 Change-Id: I93dffa647758e37f613bb5e0dfca840d82e6d26f llvm-svn: 329690
* [x86] Model the direction flag (DF) separately from the rest of EFLAGS.Chandler Carruth2018-04-101-1/+1
| | | | | | | | | | | | | | | | | | | | | This cleans up a number of operations that only claimed te use EFLAGS due to using DF. But no instructions which we think of us setting EFLAGS actually modify DF (other than things like popf) and so this needlessly creates uses of EFLAGS that aren't really there. In fact, DF is so restrictive it is pretty easy to model. Only STD, CLD, and the whole-flags writes (WRFLAGS and POPF) need to model this. I've also somewhat cleaned up some of the flag management instruction definitions to be in the correct .td file. Adding this extra register also uncovered a failure to use the correct datatype to hold X86 registers, and I've corrected that as necessary here. Differential Revision: https://reviews.llvm.org/D45154 llvm-svn: 329673
* [X86] Prevent folding loads with 64-bit ANDs with immediates that fit in ↵Craig Topper2018-04-101-0/+31
| | | | | | | | | | | | 32-bits. Prefer to use the 32-bit AND with immediate instead. Primarily I'm doing this to ensure that immediates created by shrinkAndImmediate will always get absorbed into the AND. But I do believe this would be a reduction in the number of uops that need to execute. Ideally we should shrink the 'and' and the 'load' during DAG combine to re-enable the fold. Fixes PR37063. llvm-svn: 329667
* [x86] Introduce a pass to begin more systematically fixing PR36028 and ↵Chandler Carruth2018-04-1012-3691/+3690
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | similar issues. The key idea is to lower COPY nodes populating EFLAGS by scanning the uses of EFLAGS and introducing dedicated code to preserve the necessary state in a GPR. In the vast majority of cases, these uses are cmovCC and jCC instructions. For such cases, we can very easily save and restore the necessary information by simply inserting a setCC into a GPR where the original flags are live, and then testing that GPR directly to feed the cmov or conditional branch. However, things are a bit more tricky if arithmetic is using the flags. This patch handles the vast majority of cases that seem to come up in practice: adc, adcx, adox, rcl, and rcr; all without taking advantage of partially preserved EFLAGS as LLVM doesn't currently model that at all. There are a large number of operations that techinaclly observe EFLAGS currently but shouldn't in this case -- they typically are using DF. Currently, they will not be handled by this approach. However, I have never seen this issue come up in practice. It is already pretty rare to have these patterns come up in practical code with LLVM. I had to resort to writing MIR tests to cover most of the logic in this pass already. I suspect even with its current amount of coverage of arithmetic users of EFLAGS it will be a significant improvement over the current use of pushf/popf. It will also produce substantially faster code in most of the common patterns. This patch also removes all of the old lowering for EFLAGS copies, and the hack that forced us to use a frame pointer when EFLAGS copies were found anywhere in a function so that the dynamic stack adjustment wasn't a problem. None of this is needed as we now lower all of these copies directly in MI and without require stack adjustments. Lots of thanks to Reid who came up with several aspects of this approach, and Craig who helped me work out a couple of things tripping me up while working on this. Differential Revision: https://reviews.llvm.org/D45146 llvm-svn: 329657
* ShadowCallStack/x86_64: Ignore pseudo-machine instructionsVlad Tsyrklevich2018-04-101-0/+8
| | | | llvm-svn: 329656
* [X86] Added missing AAD/AAM immediate schedule testsSimon Pilgrim2018-04-092-6/+62
| | | | | | Added some more TODOs for missing instructions llvm-svn: 329626
* [X86] Don't use Lower512IntUnary to split bitcasts with v32i16/v64i8 types ↵Craig Topper2018-04-091-0/+22
| | | | | | | | | | | | | | on targets without AVX512BW. LowerIntUnary as its name says has an assert for integer types. But for the bitcast case one side might be an FP type. Rather than making sure the function really works for fp types and renaming it. Just do really basic splitting directly. The LowerIntUnary has the advantage that it can peek through BUILD_VECTOR because every other call is during Lowering. But these calls are during legalization and will be followed by a DAG combine round. Revert some change to LowerVectorIntUnary that were originally made just to make these two calls work even in pure integer cases. This was found purely by compiling the avx512f-builtins.c test from clang so I've copied over the offending function from that. llvm-svn: 329616
* AArch64: Allow offsets to be folded into addresses with ELF.Peter Collingbourne2018-04-0911-127/+191
| | | | | | | | | | | | | | | This is a code size win in code that takes offseted addresses frequently, such as C++ constructors that typically need to compute an offseted address of a vtable. It reduces the size of Chromium for Android's .text section by 46KB, or 56KB with ThinLTO (which exposes more opportunities to use a direct access rather than a GOT access). Because the addend range is limited in COFF and Mach-O, this is enabled for ELF only. Differential Revision: https://reviews.llvm.org/D45199 llvm-svn: 329611
* Revert "AMDGPU: enable 128-bit for local addr space under an option"Alex Shlyapnikov2018-04-096-14/+14
| | | | | | | | | | | | | | This reverts commit r329591. It breaks various bots: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/16516 http://lab.llvm.org:8011/builders/clang-ppc64be-linux/builds/17374 http://lab.llvm.org:8011/builders/clang-ppc64le-linux/builds/15992 http://lab.llvm.org:8011/builders/clang-ppc64be-linux-lnt http://lab.llvm.org:8011/builders/clang-ppc64le-linux-lnt/builds/11251 ... llvm-svn: 329610
* [X86] Remove GCCBuiltin name from pmuldq/pmuludq intrinsics so clang can ↵Craig Topper2018-04-095-14/+383
| | | | | | | | | | custom lower to native IR. Update fast-isel intrinsic tests for clang's new codegen. In somes cases fast-isel fails to remove the and/shifts and uses blends or conditional moves. But once masking gets involved, fast-isel aborts on the mask portion and we DAG combine more thorougly. llvm-svn: 329604
* [X86] Revert the SLM part of r328914.Craig Topper2018-04-092-22/+24
| | | | | | While it appears to be correct information based on Intel's optimization manual and Agner's data, it causes perf regressions on a couple of the benchmarks in our internal list. llvm-svn: 329593
* AMDGPU: enable 128-bit for local addr space under an optionMarek Olsak2018-04-096-14/+14
| | | | | | | | | | | | | | | | | Author: Samuel Pitoiset ds_read_b128 and ds_write_b128 have been recently enabled under the amdgpu-ds128 option because the performance benefit is unclear. Though, using 128-bit loads/stores for the local address space appears to introduce regressions in tessellation shaders. Not sure what is broken, but as ds_read_b128/ds_write_b128 are not enabled by default, just introduce a global option and enable 128-bit only if requested (until it's fixed/used correctly). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105464 llvm-svn: 329591
* [X86][SSE] Add floating point add/mul strict (ordered) vector.reduce tests ↵Simon Pilgrim2018-04-092-0/+3523
| | | | | | (PR36732) llvm-svn: 329587
OpenPOWER on IntegriCloud