summaryrefslogtreecommitdiffstats
path: root/llvm/test/MC/X86/AlignedBundling
Commit message (Collapse)AuthorAgeFilesLines
* [lit] Delete empty lines at the end of lit.local.cfg NFCFangrui Song2019-06-171-1/+0
| | | | llvm-svn: 363538
* [llvm-readobj] Change -long-option to --long-option in tests. NFCFangrui Song2019-05-011-1/+1
| | | | | | | | | | We use both -long-option and --long-option in tests. Switch to --long-option for consistency. In the "llvm-readelf" mode, -long-option is discouraged as it conflicts with grouped short options and it is not accepted by GNU readelf. While updating the tests, change llvm-readobj -s to llvm-readobj -S to reduce confusion ("s" is --section-headers in llvm-readobj but --symbols in llvm-readelf). llvm-svn: 359649
* [MC] Pass MCSubtargetInfo to fixupNeedsRelaxation and applyFixupPeter Smith2018-06-061-0/+16
| | | | | | | | | | | | | | | | | | On targets like Arm some relaxations may only be performed when certain architectural features are available. As functions can be compiled with differing levels of architectural support we must make a judgement on whether we can relax based on the MCSubtargetInfo for the function. This change passes through the MCSubtargetInfo for the function to fixupNeedsRelaxation so that the decision on whether to relax can be made per function. In this patch, only the ARM backend makes use of this information. We must also pass the MCSubtargetInfo to applyFixup because some fixups skip error checking on the assumption that relaxation has occurred, to prevent code-generation errors applyFixup must see the same MCSubtargetInfo as fixupNeedsRelaxation. Differential Revision: https://reviews.llvm.org/D44928 llvm-svn: 334078
* [X86] Emit 11-byte or 15-byte NOPs on recent AMD targets, else default to ↵Simon Pilgrim2018-01-294-8/+11
| | | | | | | | | | | | 10-byte NOPs (PR22965) We currently emit up to 15-byte NOPs on all targets (apart from Silvermont), which stalls performance on some targets with decoders that struggle with 2 or 3 more '66' prefixes. This patch flags recent AMD targets (btver1/znver1) to still emit 15-byte NOPs and bdver* targets to emit 11-byte NOPs. All other targets now emit 10-byte NOPs apart from SilverMont CPUs which still emit 7-byte NOPS. Differential Revision: https://reviews.llvm.org/D42616 llvm-svn: 323693
* [X86] Don't use NOPL when the assembler is passed an empty CPU string. ↵Craig Topper2017-12-188-16/+16
| | | | | | | | | | Update tests to force a CPU with NOPL Empty string should be equivalent to "generic" which doesn't allow NOPL. Force tests to use specificy 'pentiumpro' to guarantee NOPL. Fixes PR35686 llvm-svn: 321026
* Revert r265817Colin LeMahieu2016-04-085-11/+11
| | | | | | lld tests need to be addressed. llvm-svn: 265822
* [llvm-objdump] Printing hex instead of dec by defaultColin LeMahieu2016-04-085-11/+11
| | | | | | Differential Revision: http://reviews.llvm.org/D18770 llvm-svn: 265817
* [llvm-objdump] Require that jump targets shown in -d are functionsDavid Majnemer2015-07-091-0/+4
| | | | | | | Don't let the disassembler pick call <.text> if a function happens to live at the start of the section by only using function symbols. llvm-svn: 241830
* [llvm-objdump] Print the call target next to the instructionDavid Majnemer2015-07-071-11/+11
| | | | | | | GNU binutils provides this behavior. objdump -r doesn't really help when you aren't dealing with relocation object files. llvm-svn: 241631
* [MC] Ensure that pending labels are flushed when -mc-relax-all flag is usedPetr Hosek2015-06-271-0/+30
| | | | | | | | | | | | | | | | | | | | | | | | Summary: The current implementation doesn't always flush all pending labels beforeemitting data which can result in an incorrectly placed labels in case when when instruction bundling is enabled and -mc-relax-all flag is being used. To address this issue, we always flush pending labels before emitting data. The change was tested by running PNaCl toolchain trybots with -mc-relax-all flag set. Fixes https://code.google.com/p/nativeclient/issues/detail?id=4063 Test Plan: Regression test attached Reviewers: mseaborn Subscribers: jfb, llvm-commits Differential Revision: http://reviews.llvm.org/D10325 llvm-svn: 240870
* [MC] Align fragments when -mc-relax-all flag is usedPetr Hosek2015-06-272-0/+54
| | | | | | | | | | | | | | | | | | | | | | | Summary: Ensure that fragments are bundle aligned when instruction bundling is enabled and the -mc-relax-all flag is set. This is implicitly assumed by the bundle padding implementation but this assumption does not hold when custom alignment is being used. The change was tested by running PNaCl toolchain trybots with -mc-relax-all flag set. Fixes https://code.google.com/p/nativeclient/issues/detail?id=4063 Test Plan: Regression test attached Reviewers: mseaborn Subscribers: jfb, llvm-commits Differential Revision: http://reviews.llvm.org/D10044 llvm-svn: 240869
* Tighten bundling section alignment test.Derek Schuff2015-04-211-0/+2
| | | | | | Leftover comment from http://reviews.llvm.org/D9131 llvm-svn: 235366
* [MC] When using bundle aligment, align sections to bundle sizeDerek Schuff2015-04-211-0/+21
| | | | | | | | | | | | | | | Summary: Bundle aligment requires that the functions always start at an aligned address. Usually this is ensured by the compiler, but assembly code does not always begin with a .align directive. This change ensures that sections get the correct alignment if they contain any instructions and bundling is enabled. (It also makes LLVM match the behavior of GNU as). Differential Revision: http://reviews.llvm.org/D9131 llvm-svn: 235365
* [MC] Write padding into fragments when -mc-relax-all flag is usedPetr Hosek2015-04-1210-4/+26
| | | | | | | | | | | | | | | | | | Summary: When instruction bundling is enabled and the -mc-relax-all flag is set, we can write bundle padding directly into fragments and avoid creating large number of fragments significantly reducing LLVM MC memory usage. Test Plan: Regression test attached Reviewers: eliben Subscribers: jfb, mseaborn Differential Revision: http://reviews.llvm.org/D8072 llvm-svn: 234714
* [MC] Attach labels to existing fragments instead of using a separate fragmentDerek Schuff2014-10-222-1/+84
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Currently when emitting a label, a new data fragment is created for it if the current fragment isn't a data fragment. This change instead enqueues the label and attaches it to the next fragment (e.g. created for the next instruction) if possible. When bundle alignment is not enabled, this has no functionality change (it just results in fewer extra fragments being created). For bundle alignment, previously labels would point to the beginning of the bundle padding instead of the beginning of the emitted instruction. This was not only less efficient (e.g. jumping to the nops instead of past them) but also led to miscalculation of the address of the GOT (since MC uses a label difference rather than emitting a "." symbol). Fixes https://code.google.com/p/nativeclient/issues/detail?id=3982 Test Plan: regression test attached Reviewers: jvoung, eliben Subscribers: jfb, llvm-commits Differential Revision: http://reviews.llvm.org/D5915 llvm-svn: 220439
* [MC] Make bundle alignment mode setting idempotent and support nested bundlesDerek Schuff2014-10-151-0/+67
| | | | | | | | | | | | | | | | | | | | | | Summary: Currently an error is thrown if bundle alignment mode is set more than once per module (either via the API or the .bundle_align_mode directive). This change allows setting it multiple times as long as the alignment doesn't change. Also nested bundle_lock groups are currently not allowed. This change allows them, with the effect that the group stays open until all nests are exited, and if any of the bundle_lock directives has the align_to_end flag, the group becomes align_to_end. These changes make the bundle aligment simpler to use in the compiler, and also better match the corresponding support in GNU as. Reviewers: jvoung, eliben Differential Revision: http://reviews.llvm.org/D5801 llvm-svn: 219811
* Reduce verbiage of lit.local.cfg filesAlp Toker2014-06-091-2/+1
| | | | | | We can just split targets_to_build in one place and make it immutable. llvm-svn: 210496
* [tests] Cleanup initialization of test suffixes.Daniel Dunbar2013-08-161-2/+0
| | | | | | | | | | | | | | | | | - Instead of setting the suffixes in a bunch of places, just set one master list in the top-level config. We now only modify the suffix list in a few suites that have one particular unique suffix (.ml, .mc, .yaml, .td, .py). - Aside from removing the need for a bunch of lit.local.cfg files, this enables 4 tests that were inadvertently being skipped (one in Transforms/BranchFolding, a .s file each in DebugInfo/AArch64 and CodeGen/PowerPC, and one in CodeGen/SI which is now failing and has been XFAILED). - This commit also fixes a bunch of config files to use config.root instead of older copy-pasted code. llvm-svn: 188513
* Prefix failing commands with not to make clear they are expected to fail.Rafael Espindola2013-07-036-6/+6
| | | | llvm-svn: 185554
* The current X86 NOP padding uses one long NOP followed by the remainder inDavid Sehr2013-03-051-0/+27
| | | | | | | | | | | one-byte NOPs. If the processor actually executes those NOPs, as it sometimes does with aligned bundling, this can have a performance impact. From my micro-benchmarks run on my one machine, a 15-byte NOP followed by twelve one-byte NOPs is about 20% worse than a 15 followed by a 12. This patch changes NOP emission to emit as many 15-byte (the maximum) as possible followed by at most one shorter NOP. llvm-svn: 176464
* [MC] Bundle alignment: Invalidate relaxed fragmentsDerek Schuff2013-02-051-0/+16
| | | | | | | | | | | | | | | | Currently, when a fragment is relaxed, its size is modified, but its offset is not (it gets laid out as a side effect of checking whether it needs relaxation), then all subsequent fragments are invalidated because their offsets need to change. When bundling is enabled, relaxed fragments need to get laid out again, because the increase in size may push it over a bundle boundary. So instead of only invalidating subsequent fragments, also invalidate the fragment that gets relaxed, which causes it to get laid out again. This patch also fixes some trailing whitespace and fixes the bundling-related debug output of MCFragments. llvm-svn: 174401
* [MC] bundle alignment: prevent padding instructions from crossing bundle ↵Derek Schuff2013-01-312-2/+108
| | | | | | boundaries llvm-svn: 174067
* Add some additional tests for the .bundle_lock align_to_end feature that didn'tEli Bendersky2013-01-073-0/+2837
| | | | | | | | | make into the last commit. Also, update the test-generation script to generate an exhaustive test for align_to_end as well, and include the generated test. llvm-svn: 171811
* Add the align_to_end option to .bundle_lock in the MC implementation of alignedEli Bendersky2013-01-071-0/+4
| | | | | | | | | bundling. The document describing this feature and the implementation has also been updated: https://sites.google.com/a/chromium.org/dev/nativeclient/pnacl/aligned-bundling-support-in-llvm llvm-svn: 171797
* Change Lit error redirection to FileCheck to a more common syntax since itEli Bendersky2012-12-206-6/+6
| | | | | | can potentially cause some bots to fail. llvm-svn: 170726
* Add a largish auto-generated test for the aligned bundling feature, along withEli Bendersky2012-12-201-0/+2674
| | | | | | | | | | the script generating it. The test should never be modified manually. If anyone needs to change it, please change the script and re-run it. The script is placed into utils/testgen - I couldn't think of a better place, and after some discussion on IRC this looked like a logical location. llvm-svn: 170720
* Tests for the aligned bundling support added in r170718Eli Bendersky2012-12-2011-0/+246
llvm-svn: 170719
OpenPOWER on IntegriCloud