summaryrefslogtreecommitdiffstats
path: root/llvm/lib
Commit message (Collapse)AuthorAgeFilesLines
...
* RegBankSelect: Support some more complex part mappingsMatt Arsenault2019-01-245-25/+295
| | | | llvm-svn: 352123
* [PDB] Increase TPI hash bucket count.Zachary Turner2019-01-241-2/+2
| | | | | | | | | | | | | | | PDBs contain several serialized hash tables. In the microsoft-pdb repo published to support LLVM implementing PDB support, the provided initializes the bucket count for the TPI and IPI streams to the maximum size. This occurs in tpi.cpp L33 and tpi.cpp L398. In the LLVM code for generating PDBs, these streams are created with minimum number of buckets. This difference makes LLVM generated PDBs slower for when used for debugging. Patch by C.J. Hebert Differential Revision: https://reviews.llvm.org/D56942 llvm-svn: 352117
* [GlobalISel][AArch64] Add isel support for FP16 vector @llvm.ceilJessica Paquette2019-01-244-94/+484
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds support for vector @llvm.ceil intrinsics when full 16 bit floating point support isn't available. To do this, this patch... - Implements basic isel for G_UNMERGE_VALUES - Teaches the legalizer about 16 bit floats - Teaches AArch64RegisterBankInfo to respect floating point registers on G_BUILD_VECTOR and G_UNMERGE_VALUES - Teaches selectCopy about 16-bit floating point vectors It also adds - A legalizer test for the 16-bit vector ceil which verifies that we create a G_UNMERGE_VALUES and G_BUILD_VECTOR when full fp16 isn't supported - An instruction selection test which makes sure we lower to G_FCEIL when full fp16 is supported - A test for selecting G_UNMERGE_VALUES And also updates arm64-vfloatintrinsics.ll to show that the new ceiling types work as expected. https://reviews.llvm.org/D56682 llvm-svn: 352113
* allow COFF .def directive in module assembly when using ThinLTOBob Haarman2019-01-241-0/+9
| | | | | | | | | | | | | | | | | | | | Summary: Using COFF's .def directive in module assembly used to crash ThinLTO with "this directive only supported on COFF targets" when getting symbol information in ModuleSymbolTable. This change allows ModuleSymbolTable to process such code and adds a test to verify that the .def directive has the desired effect on the native object file, with and without ThinLTO. Fixes https://bugs.llvm.org/show_bug.cgi?id=36789 Reviewers: rnk, pcc, vlad.tsyrklevich Subscribers: mehdi_amini, eraman, hiraditya, dexonsmith, llvm-commits Differential Revision: https://reviews.llvm.org/D57073 llvm-svn: 352112
* [Analysis] Fix isSafeToLoadUnconditionally handling of volatile.Eli Friedman2019-01-241-0/+8
| | | | | | | | | A volatile operation cannot be used to prove an address points to normal memory. (LangRef was recently updated to state it explicitly.) Differential Revision: https://reviews.llvm.org/D57040 llvm-svn: 352109
* Limit dyld image suffixes guessed by guessLibraryShortName()Michael Trent2019-01-241-3/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: guessLibraryShortName() separates a full Mach-O dylib install name path into a short name and a dyld image suffix. The short name is the name of the dylib without its path or extension. The dyld image suffix is a string used by dyld to load variants of dylibs if available at runtime; for example, "when binding this process, load 'debug' variants of all required dylibs." dyld knows exactly what the image suffix is, but by convention diagnostic tools such as llvm-nm attempt to guess suffix names by looking at the install name path. These dyld image suffixes are separated from the short name by a '_' character. Because the '_' character is commonly used to separate words in filenames guessLibraryShortName() cannot reliably separate a dylib's short name from an arbitrary image suffix; imagine if both the short name and the suffix contains an '_' character! To better deal with this ambiguity, guessLibraryShortName() will recognize only "_debug" and "_profile" as valid Suffix values. Calling code needs to be tolerant of guessLibraryShortName() guessing incorrectly. The previous implementation of guessLibraryShortName() did not allow '_' characters to appear in short names. When present, the short name would be truncated, e.g., "libcompiler_rt" => "libcompiler". This change allows "libcompiler_rt" and "libcompiler_rt_debug" to both be recognized as "libcompiler_rt". rdar://47412244 Reviewers: kledzik, lhames, pete Reviewed By: pete Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D56978 llvm-svn: 352104
* Fix a compiler error introduced in r352093.Haojian Wu2019-01-241-1/+1
| | | | llvm-svn: 352098
* [LICM] Cleanup duplicated code. [NFCI]Alina Sbirlea2019-01-241-17/+11
| | | | llvm-svn: 352093
* [MemorySSA +LICM CFHoist] Solve PR40317.Alina Sbirlea2019-01-241-0/+5
| | | | | | | | | | | | | | | Summary: MemorySSA needs updating each time an instruction is moved. LICM and control flow hoisting re-hoists instructions, thus needing another update when re-moving those instructions. Pending cleanup: the MSSA update is duplicated, should be moved inside moveInstructionBefore. Reviewers: jnspaulsson Subscribers: sanjoy, jlebar, Prazek, george.burgess.iv, llvm-commits Differential Revision: https://reviews.llvm.org/D57176 llvm-svn: 352092
* [HotColdSplit] Move splitting earlier in the pipelineVedant Kumar2019-01-242-9/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Performing splitting early has several advantages: - Inhibiting inlining of cold code early improves code size. Compared to scheduling splitting at the end of the pipeline, this cuts code size growth in half within the iOS shared cache (0.69% to 0.34%). - Inhibiting inlining of cold code improves compile time. There's no need to inline split cold functions, or to inline as much *within* those split functions as they are marked `minsize`. - During LTO, extra work is only done in the pre-link step. Less code must be inlined during cross-module inlining. An additional motivation here is that the most common cold regions identified by the static/conservative splitting heuristic can (a) be found before inlining and (b) do not grow after inlining. E.g. __assert_fail, os_log_error. The disadvantages are: - Some opportunities for splitting out cold code may be missed. This gap can potentially be narrowed by adding a worklist algorithm to the splitting pass. - Some opportunities to reduce code size may be lost (e.g. store sinking, when one side of the CFG diamond is split). This does not outweigh the code size benefits of splitting earlier. On net, splitting early in the pipeline has substantial code size benefits, and no major effects on memory locality or performance. We measured memory locality using ktrace data, and consistently found that 10% fewer pages were needed to capture 95% of text page faults in key iOS benchmarks. We measured performance on frequency-stabilized iOS devices using LNT+externals. This reverses course on the decision made to schedule splitting late in r344869 (D53437). Differential Revision: https://reviews.llvm.org/D57082 llvm-svn: 352080
* [x86] rename VectorShuffle -> Shuffle; NFCSanjay Patel2019-01-241-706/+631
| | | | | | | This wasn't consistent within the file, so made it harder to search. Standardize on the shorter name to save some typing. llvm-svn: 352077
* Fix emission of _fltused for MSVC.James Y Knight2019-01-245-43/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | It should be emitted when any floating-point operations (including calls) are present in the object, not just when calls to printf/scanf with floating point args are made. The difference caused by this is very subtle: in static (/MT) builds, on x86-32, in a program that uses floating point but doesn't print it, the default x87 rounding mode may not be set properly upon initialization. This commit also removes the walk of the types pointed to by pointer arguments in calls. (To assist in opaque pointer types migration -- eventually the pointee type won't be available.) That latter implies that it will no longer consider a call like `scanf("%f", &floatvar)` as sufficient to emit _fltused on its own. And without _fltused, `scanf("%f")` will abort with error R6002. This new behavior is unlikely to bite anyone in practice (you'd have to read a float, and do nothing with it!), and also, is consistent with MSVC. Differential Revision: https://reviews.llvm.org/D56548 llvm-svn: 352076
* Revert "[Sanitizers] UBSan unreachable incompatible with ASan in the ↵Julian Lettner2019-01-2410-19/+3
| | | | | | | | presence of `noreturn` calls" This reverts commit cea84ab93aeb079a358ab1c8aeba6d9140ef8b47. llvm-svn: 352069
* [SelectionDAGBuilder] Simplify HasSideEffect calculation. NFC.Nirav Dave2019-01-241-13/+7
| | | | llvm-svn: 352067
* [InlineAsm] Don't calculate registers for inline asm memory operands. NFCI.Nirav Dave2019-01-241-0/+4
| | | | llvm-svn: 352066
* [x86] add low/high undef half shuffle mask helpers; NFCSanjay Patel2019-01-241-8/+19
| | | | | | | | This is the most common usage for isUndefInRange, so make the code slightly less duplicated and more readable. llvm-svn: 352063
* [RS4GC] Be slightly less conservative for gep vector_base, scalar_idxPhilip Reames2019-01-241-11/+10
| | | | | | | | After submitting https://reviews.llvm.org/D57138, I realized it was slightly more conservative than needed. The scalar indices don't appear to be a problem on a vector gep, we even had a test for that. Differential Revision: https://reviews.llvm.org/D57161 llvm-svn: 352061
* [RS4GC] Avoid crashing on gep scalar_base, vector_idxPhilip Reames2019-01-241-0/+28
| | | | | | | | | | | | This is an alternative to https://reviews.llvm.org/D57103. After discussion, we dedicided to check this in as a temporary workaround, and pursue a true fix under the original thread. The issue at hand is that the base rewriting algorithm doesn't consider the fact that GEPs can turn a scalar input into a vector of outputs. We had handling for scalar GEPs and fully vector GEPs (i.e. all vector operands), but not the scalar-base + vector-index forms. A true fix here requires treating GEP analogously to extractelement or shufflevector. This patch is merely a workaround. It simply hides the crash at the cost of some ugly code gen for this presumable very rare pattern. Differential Revision: https://reviews.llvm.org/D57138 llvm-svn: 352059
* [TargetLowering] Rename getExpandedFixedPointMultiplication to ↵Simon Pilgrim2019-01-242-3/+2
| | | | | | | | expandFixedPointMul. NFCI. Match the (much shorter) name used in various legalization methods. llvm-svn: 352056
* [SelectionDAGBuilder] Fuse inline asm input operand loops passes. NFCI.Nirav Dave2019-01-241-13/+9
| | | | llvm-svn: 352053
* [X86] Add missing isReg() guards in FixupSetCCs pass.Nirav Dave2019-01-241-2/+2
| | | | llvm-svn: 352051
* [TTI] Add generic SADDO/SSUBO costsSimon Pilgrim2019-01-241-0/+10
| | | | | | Added x86 scalar sadd_with_overflow/ssub_with_overflow costs. llvm-svn: 352045
* [TTI] Add generic UADDO/USUBO costsSimon Pilgrim2019-01-241-3/+14
| | | | | | | | Added x86 scalar uadd_with_overflow/usub_with_overflow costs. Differential Revision: https://reviews.llvm.org/D56907 llvm-svn: 352043
* Revert "[HotColdSplitting] Get DT and PDT from the pass manager."Florian Hahn2019-01-241-32/+9
| | | | | | | | | This reverts commit a6982414edf315c39ae93f3c3322476217119e99 (llvm-svn: 352036), because it causes a memory leak in the pass manager. Failing bot http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/builds/10351/steps/check-llvm%20asan/logs/stdio llvm-svn: 352041
* [MIPS GlobalISel] Select zero extending and sign extending loadPetar Avramovic2019-01-243-2/+37
| | | | | | | | | Select zero extending and sign extending load for MIPS32. Use size from MachineMemOperand to determine number of bytes to load. Differential Revision: https://reviews.llvm.org/D57099 llvm-svn: 352038
* [MIPS GlobalISel] Combine extending loadsPetar Avramovic2019-01-241-0/+11
| | | | | | | | | | | | | | Use CombinerHelper to combine extending load instructions. G_LOAD combined with G_ZEXT, G_SEXT or G_ANYEXT gives G_ZEXTLOAD, G_SEXTLOAD or G_LOAD with same type as def of extending instruction respectively. Similarly G_ZEXTLOAD combined with G_ZEXT gives G_ZEXTLOAD and G_SEXTLOAD combined with G_SEXT gives G_SEXTLOAD with same type as def of extending instruction. Differential Revision: https://reviews.llvm.org/D56914 llvm-svn: 352037
* [HotColdSplitting] Get DT and PDT from the pass manager.Florian Hahn2019-01-241-9/+32
| | | | | | | | | | | | | | | | | | | Instead of manually computing DT and PDT, we can get the from the pass manager, which ideally has them already cached. With the new pass manager, we could even preserve DT/PDT on a per function basis in a module pass. I think this also addresses the TODO about re-using the computed DTs for BFI. IIUC, GetBFI will fetch the DT from the pass manager and when we will fetch the cached version later. Reviewers: vsk, hiraditya, tejohnson, thegameg, sebpop Reviewed By: vsk Differential Revision: https://reviews.llvm.org/D57092 llvm-svn: 352036
* Reapply: [mips] Handle MipsMCExpr sub-expression for the MEK_DTPREL tagSimon Atanasyan2019-01-242-8/+11
| | | | | | | | | | | | | | | | | | | | | This reapplies commit r351987 with a failed test fix. Now the test accepts both DW_OP_GNU_push_tls_address and DW_OP_form_tls_address opcode. Original commit message: ``` This is a fix for a regression introduced by the rL348194 commit. In that change new type (MEK_DTPREL) of MipsMCExpr expression was added, but in some places of the code this type of expression considered as unexpected. This change fixes the bug. The MEK_DTPREL type of expression is used for marking TLS DIEExpr only and contains a regular sub-expression. Where we need to handle the expression, we retrieve the sub-expression and handle it in a common way. ``` llvm-svn: 352034
* [SystemZ] Remember to reset the NoPHIs property on MF in createPHIsForSelects()Jonas Paulsson2019-01-241-0/+2
| | | | | | | | After creating new PHI instructions during isel pseudo expansion, the NoPHIs property of MF should be reset in case it was previously set. Review: Ulrich Weigand llvm-svn: 352030
* [X86] Update SelectionDAGDumper to print the extension type and expanding ↵Craig Topper2019-01-241-0/+30
| | | | | | flag for masked loads. Add truncating and compressing for masked stores. llvm-svn: 352029
* [X86] Add test cases for opportunities to fold a truncate and a masked store ↵Craig Topper2019-01-241-1/+1
| | | | | | into a truncating masked store. llvm-svn: 352027
* [LoopSimplifyCFG] Fix inconsistency in live blocks markupMax Kazantsev2019-01-241-2/+3
| | | | | | | | | | | | | | | | | | | | | | When we choose whether or not we should mark block as dead, we have an inconsistent logic in markup of live blocks. - We take candidate IF its terminator branches on constant AND it is immediately in current loop; - We mark successor live IF its terminator doesn't branch by constant OR it branches by constant and the successor is its always taken block. What we are missing here is that when the terminator branches on a constant but is not taken as a candidate because is it not immediately in the current loop, we will mark only one (always taken) successor as live. Therefore, we do NOT do the actual folding but may NOT mark one of the successors as live. So the result of markup is wrong in this case, and we may then hit various asserts. Thanks Jordan Rupprech for reporting this! Differential Revision: https://reviews.llvm.org/D57095 Reviewed By: rupprecht llvm-svn: 352024
* DebugInfo: Use assembly label arithmetic for address pool size for easier ↵David Blaikie2019-01-242-9/+17
| | | | | | | | | reading/editing Recommits 350048, 350050 That broke buildbots because of some typos in the test case. llvm-svn: 352019
* Revert "[RISCV] Set isAsCheapAsAMove for ADDI, ORI, XORI, LUI"Ana Pazos2019-01-243-18/+3
| | | | | | | | This reverts commit ccfb060ecb5d7e18ea729455660484d576bde2cc. Some tests need to to fixed before reapplying this commit. llvm-svn: 352014
* [RISCV] Set isAsCheapAsAMove for ADDI, ORI, XORI, LUIAna Pazos2019-01-243-3/+18
| | | | | | | | | | | | | | | | | Summary: Affected instructions: PseudoLI simplest form (ADDI with X0) ALU operations with immediate (they do not set status flag - ADDI, ORI, XORI) Reviewers: asb Reviewed By: asb Subscribers: shiva0217, rkruppe, kito-cheng, asb, rbar, johnrusso, simoncook, sabuasal, niosHD, zzheng, edward-jones, mgrang, rogfer01, MartinMosbeck, brucehoult, the_o, PkmX, jocewei Differential Revision: https://reviews.llvm.org/D56526 llvm-svn: 352010
* [RISCV] Set isReMaterializable for ORI, XORIAna Pazos2019-01-241-0/+4
| | | | | | | | | | | | Reviewers: asb Reviewed By: asb Subscribers: asb, rbar, johnrusso, simoncook, sabuasal, niosHD, kito-cheng, shiva0217, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, PkmX, jocewei Differential Revision: https://reviews.llvm.org/D57069 llvm-svn: 352008
* [Sanitizers] UBSan unreachable incompatible with ASan in the presence of ↵Julian Lettner2019-01-2410-3/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `noreturn` calls Summary: UBSan wants to detect when unreachable code is actually reached, so it adds instrumentation before every `unreachable` instruction. However, the optimizer will remove code after calls to functions marked with `noreturn`. To avoid this UBSan removes `noreturn` from both the call instruction as well as from the function itself. Unfortunately, ASan relies on this annotation to unpoison the stack by inserting calls to `_asan_handle_no_return` before `noreturn` functions. This is important for functions that do not return but access the the stack memory, e.g., unwinder functions *like* `longjmp` (`longjmp` itself is actually "double-proofed" via its interceptor). The result is that when ASan and UBSan are combined, the `noreturn` attributes are missing and ASan cannot unpoison the stack, so it has false positives when stack unwinding is used. Changes: # UBSan now adds the `expect_noreturn` attribute whenever it removes the `noreturn` attribute from a function # ASan additionally checks for the presence of this attribute Generated code: ``` call void @__asan_handle_no_return // Additionally inserted to avoid false positives call void @longjmp call void @__asan_handle_no_return call void @__ubsan_handle_builtin_unreachable unreachable ``` The second call to `__asan_handle_no_return` is redundant. This will be cleaned up in a follow-up patch. rdar://problem/40723397 Reviewers: delcypher, eugenis Tags: #sanitizers Differential Revision: https://reviews.llvm.org/D56624 llvm-svn: 352003
* Update entry count for cold callsDavid Callahan2019-01-242-37/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Profile sample files include the number of times each entry or inlined call site is sampled. This is translated into the entry count metadta on functions. When sample data is being read, if a call site that was inlined in the sample program is considered cold and not inlined, then the entry count of the out-of-line functions does not reflect the current compilation. In this patch, we note call sites where the function was not inlined and as a last action of the sample profile loading, we update the called function's entry count to reflect the calls from these call sites which are not included in the profile file. Reviewers: danielcdh, wmi, Kader, modocache Reviewed By: wmi Subscribers: davidxl, eraman, llvm-commits Differential Revision: https://reviews.llvm.org/D52845 llvm-svn: 352001
* Revert "[mips] Handle MipsMCExpr sub-expression for the MEK_DTPREL tag"Amara Emerson2019-01-242-11/+8
| | | | | | This reverts commit r351987 as it broke some bots. llvm-svn: 351998
* [llvm] Clarify responsiblity of some of DILocation discriminator APIsMircea Trofin2019-01-244-5/+5
| | | | | | | | | | | | | | | | | | | | | Summary: Renamed setBaseDiscriminator to cloneWithBaseDiscriminator, to match similar APIs. Also changed its behavior to copy over the other discriminator components, instead of eliding them. Renamed cloneWithDuplicationFactor to cloneByMultiplyingDuplicationFactor, which more closely matches what this API does. Reviewers: dblaikie, wmi Reviewed By: dblaikie Subscribers: zzheng, llvm-commits Differential Revision: https://reviews.llvm.org/D56220 llvm-svn: 351996
* [ADT] Notify ilist traits about in-list transfersReid Kleckner2019-01-232-3/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Previously no client of ilist traits has needed to know about transfers of nodes within the same list, so as an optimization, ilist doesn't call transferNodesFromList in that case. However, now there are clients that want to use ilist traits to cache instruction ordering information to optimize dominance queries of instructions in the same basic block. This change updates the existing ilist traits users to detect in-list transfers and do nothing in that case. After this change, we can start caching instruction ordering information in LLVM IR data structures. There are two main ways to do that: - by putting an order integer into the Instruction class - by maintaining order integers in a hash table on BasicBlock I plan to implement and measure both, but I wanted to commit this change first to enable other out of tree ilist clients to implement this optimization as well. Reviewers: lattner, hfinkel, chandlerc Subscribers: hiraditya, dexonsmith, llvm-commits Differential Revision: https://reviews.llvm.org/D57120 llvm-svn: 351992
* [LV][VPlan] Change to implement VPlan based predication forHideki Saito2019-01-237-6/+419
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | VPlan-native path Context: Patch Series #2 for outer loop vectorization support in LV using VPlan. (RFC: http://lists.llvm.org/pipermail/llvm-dev/2017-December/119523.html). Patch series #2 checks that inner loops are still trivially lock-step among all vector elements. Non-loop branches are blindly assumed as divergent. Changes here implement VPlan based predication algorithm to compute predicates for blocks that need predication. Predicates are computed for the VPLoop region in reverse post order. A block's predicate is computed as OR of the masks of all incoming edges. The mask for an incoming edge is computed as AND of predecessor block's predicate and either predecessor's Condition bit or NOT(Condition bit) depending on whether the edge from predecessor block to the current block is true or false edge. Reviewers: fhahn, rengolin, hsaito, dcaballe Reviewed By: fhahn Patch by Satish Guggilla, thanks! Differential Revision: https://reviews.llvm.org/D53349 llvm-svn: 351990
* hwasan: Read shadow address from ifunc if we don't need a frame record.Peter Collingbourne2019-01-231-10/+21
| | | | | | | | | | | | | This saves a cbz+cold call in the interceptor ABI, as well as a realign in both ABIs, trading off a dcache entry against some branch predictor entries and some code size. Unfortunately the functionality is hidden behind a flag because ifunc is known to be broken on static binaries on Android. Differential Revision: https://reviews.llvm.org/D57084 llvm-svn: 351989
* [mips] Handle MipsMCExpr sub-expression for the MEK_DTPREL tagSimon Atanasyan2019-01-232-8/+11
| | | | | | | | | | | | | | This is a fix for a regression introduced by the rL348194 commit. In that change new type (MEK_DTPREL) of MipsMCExpr expression was added, but in some places of the code this type of expression considered as unexpected. This change fixes the bug. The MEK_DTPREL type of expression is used for marking TLS DIEExpr only and contains a regular sub-expression. Where we need to handle the expression, we retrieve the sub-expression and handle it in a common way. llvm-svn: 351987
* Revert r351938 "[ARM] Alter the register allocation order for minsize on Thumb2"Reid Kleckner2019-01-231-27/+4
| | | | | | | This change caused fatal backend errors when compiling a file in libvpx for Android. llvm-svn: 351979
* [DEBUGINFO, NVPTX] Enable support for the debug info on NVPTX target.Alexey Bataev2019-01-234-13/+19
| | | | | | | | Enable full support for the debug info. Differential revision: https://reviews.llvm.org/D46189 llvm-svn: 351974
* Revert "[DEBUGINFO, NVPTX] Enable support for the debug info on NVPTX target."Alexey Bataev2019-01-234-18/+12
| | | | | | | This reverts commit r351972. Some pieces of the patch was not applied correctly. llvm-svn: 351973
* [DEBUGINFO, NVPTX] Enable support for the debug info on NVPTX target.Alexey Bataev2019-01-234-12/+18
| | | | | | | | | Enable full support for the debug info. Recommit to fix the emission of the not required closing brace. Differential revision: https://reviews.llvm.org/D46189 llvm-svn: 351972
* Revert "[DEBUGINFO, NVPTX] Enable support for the debug info on NVPTX target."Haojian Wu2019-01-233-8/+12
| | | | | | | | | | | | | | | | | | | | | | This reverts commit r351846. This patch may generate illegal assembly code, see ``` $ ./bin/clang -cc1 -triple nvptx64-nvidia-cuda -aux-triple x86_64-grtev4-linux-gnu -S -disable-free -disable-llvm-verifier -discard-value-names -main-file-name new.cc -mrelocation-model pic -pic-level 2 -mthread-model posix -fmerge-all-constants -mdisable-fp-elim -relaxed-aliasing -no-integrated-as -mpie-copy-relocations -munwind-tables -fcuda-is-device -target-feature +ptx60 -target-cpu sm_35 -dwarf-column-info -debug-info-kind=line-directives-only -dwarf-version=2 -debugger-tuning=gdb -o empty.s -x cuda empty.cc $ cat empty.s // // Generated by LLVM NVPTX Back-End // .version 6.0 .target sm_35 .address_size 64 } ``` llvm-svn: 351966
* [MC][X86] Correctly model additional operand latency caused by transfer ↵Andrea Di Biagio2019-01-2316-8/+68
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | delays from the integer to the floating point unit. This patch adds a new ReadAdvance definition named ReadInt2Fpu. ReadInt2Fpu allows x86 scheduling models to accurately describe delays caused by data transfers from the integer unit to the floating point unit. ReadInt2Fpu currently defaults to a delay of zero cycles (i.e. no delay) for all x86 models excluding BtVer2. That means, this patch is only a functional change for the Jaguar cpu model only. Tablegen definitions for instructions (V)PINSR* have been updated to account for the new ReadInt2Fpu. That read is mapped to the the GPR input operand. On Jaguar, int-to-fpu transfers are modeled as a +6cy delay. Before this patch, that extra delay was added to the opcode latency. In practice, the insert opcode only executes for 1cy. Most of the actual latency is actually contributed by the so-called operand-latency. According to the AMD SOG for family 16h, (V)PINSR* latency is defined by expression f+1, where f is defined as a forwarding delay from the integer unit to the fpu. When printing instruction latency from MCA (see InstructionInfoView.cpp) and LLC (only when flag -print-schedule is speified), we now need to account for any extra forwarding delays. We do this by checking if scheduling classes declare any negative ReadAdvance entries. Quoting a code comment in TargetSchedule.td: "A negative advance effectively increases latency, which may be used for cross-domain stalls". When computing the instruction latency for the purpose of our scheduling tests, we now add any extra delay to the formula. This avoids regressing existing codegen and mca schedule tests. It comes with the cost of an extra (but very simple) hook in MCSchedModel. Differential Revision: https://reviews.llvm.org/D57056 llvm-svn: 351965
OpenPOWER on IntegriCloud