summaryrefslogtreecommitdiffstats
path: root/llvm/docs
Commit message (Collapse)AuthorAgeFilesLines
* [llvm-readobj][ELF]Add demangling supportJames Henderson2019-01-171-0/+4
| | | | | | | | | | | | | | | | | | | | | This change adds demangling support to the ELF side of llvm-readobj, under the switch --demangle/-C. The following places are demangled: symbol table dumps (static and dynamic), relocation dumps (static and dynamic), addrsig dumps, call graph profile dumps, and group section signature symbols. Although GNU readelf doesn't support demangling, it is still a useful feature to have, and brings it on a par with llvm-objdump's capabilities. This fixes https://bugs.llvm.org/show_bug.cgi?id=40054. Reviewed by: grimar, rupprecht Differential Revision: https://reviews.llvm.org/D56791 llvm-svn: 351450
* Allow FP types for atomicrmw xchgMatt Arsenault2019-01-171-7/+8
| | | | llvm-svn: 351427
* [docs] Fix formatting.Eli Friedman2019-01-171-1/+1
| | | | llvm-svn: 351406
* [docs] Add more ARM/AArch64 links to CompilerWriterInfo.rst .Eli Friedman2019-01-171-4/+18
| | | | | | Also, fix a few existing links so they don't require registration. llvm-svn: 351403
* [NFC] Factor out + document build requirementsJF Bastien2019-01-161-0/+5
| | | | | | | | | | Summary: This change factors out compiler checking / warning, and documents LLVM_FORCE_USE_OLD_TOOLCHAIN. It doesn't introduce any functional changes nor policy changes, these will come late. Subscribers: mgorny, jkorous, dexonsmith, llvm-commits Differential Revision: https://reviews.llvm.org/D56799 llvm-svn: 351387
* Remove misleading line about git's lack of revision numbers.Erich Keane2019-01-161-3/+1
| | | | | Change-Id: I8a22cb4b4bef9bceee1f43381435d664c2cfd770 llvm-svn: 351357
* Bump the trunk version to 9.0.0svnHans Wennborg2019-01-162-24/+8
| | | | llvm-svn: 351320
* [llvm-symbolizer] Add -C as a short alias to -demangleDmitry Venikov2019-01-161-1/+1
| | | | | | | | | | | | | | Summary: Provides -C as alias to -demangle. Motivation: https://bugs.llvm.org/show_bug.cgi?id=40069. Reviewers: jhenderson, ruiu, rnk, fjricci Reviewed By: jhenderson, ruiu Subscribers: rupprecht, erik.pilkington, llvm-commits Differential Revision: https://reviews.llvm.org/D56591 llvm-svn: 351300
* [LangRef] Fix typo adress->address. NFCCraig Topper2019-01-161-2/+2
| | | | llvm-svn: 351279
* llvm-objdump -m -D should disassemble all text segmentsMichael Trent2019-01-151-17/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: When running llvm-objdump with the -macho option objdump will by default disassemble only the __TEXT,__text section (or __TEXT_EXEC,__text when disassembling MH_KEXT_BUNDLE files). The -disassemble-all option is treated no diferently than -disassemble. This change upates llvm-objdump's MachO parsing code to disassemble all __text sections found in a file when -disassemble-all is specified. This is useful for disassembling files with more than one __text section, or when disassembling files whose __text section is not present in __TEXT. I added a lit test case that verifies "llvm-objdump -m -d" and "llvm-objdump -m -D" produce the expected results on a reference binary. I also updated the CommandGuide documentation for llvm-objdump.rst and verified it renders correctly as man and html. rdar://42899338 Reviewers: ab, pete, lhames Reviewed By: lhames Subscribers: rupprecht, llvm-commits Differential Revision: https://reviews.llvm.org/D56649 llvm-svn: 351238
* [WebAssembly] Update release notesDerek Schuff2019-01-151-0/+2
| | | | | | | | | | Summary: Explicitly note that multithreading support is not included in the stable ABI. Differential Revision: https://reviews.llvm.org/D56681 llvm-svn: 351213
* Remove irrelevant references to legacy git repositories fromJames Y Knight2019-01-151-2/+2
| | | | | | | | | compiler identification lines in test-cases. (Doing so only because it's then easier to search for references which are actually important and need fixing.) llvm-svn: 351200
* Update GettingStarted guide to recommend that people use the newJames Y Knight2019-01-146-423/+199
| | | | | | | | | | | | | | | | | | | | | official Git repository. Remove the directions for using git-svn, and demote the prominence of the svn instructions. Also, fix a few other issues while I'm in there: * Mention LLVM_ENABLE_PROJECTS more. * Getting started doesn't need to mention test-suite, but should mention clang and the other projects. * Remove mentions of "configure", since that's long gone. I've also adjusted a few other mentions of svn to point to github, but have not done so comprehensively. Differential Revision: https://reviews.llvm.org/D56654 llvm-svn: 351130
* [WebAssembly] Add a release notes blurbDan Gohman2019-01-141-0/+11
| | | | | | | | Bid farewell to LLVM_EXPERIMENTAL_TARGETS_TO_BUILD! Differential Revision: https://reviews.llvm.org/D56648 llvm-svn: 351083
* Replace "no-frame-pointer-*" function attributes with "frame-pointer"Francis Visoiu Mistrih2019-01-141-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Part of the effort to refactoring frame pointer code generation. We used to use two function attributes "no-frame-pointer-elim" and "no-frame-pointer-elim-non-leaf" to represent three kinds of frame pointer usage: (all) frames use frame pointer, (non-leaf) frames use frame pointer, (none) frame use frame pointer. This CL makes the idea explicit by using only one enum function attribute "frame-pointer" Option "-frame-pointer=" replaces "-disable-fp-elim" for tools such as llc. "no-frame-pointer-elim" and "no-frame-pointer-elim-non-leaf" are still supported for easy migration to "frame-pointer". tests are mostly updated with // replace command line args ‘-disable-fp-elim=false’ with ‘-frame-pointer=none’ grep -iIrnl '\-disable-fp-elim=false' * | xargs sed -i '' -e "s/-disable-fp-elim=false/-frame-pointer=none/g" // replace command line args ‘-disable-fp-elim’ with ‘-frame-pointer=all’ grep -iIrnl '\-disable-fp-elim' * | xargs sed -i '' -e "s/-disable-fp-elim/-frame-pointer=all/g" Patch by Yuanfang Chen (tabloid.adroit)! Differential Revision: https://reviews.llvm.org/D56351 llvm-svn: 351049
* [llvm-symbolizer] Add -addresses, -a as aliases for -print-addressDmitry Venikov2019-01-141-1/+1
| | | | | | | | | | | | | | Summary: Provides -addresses, -a as aliases for -print-address. Motivation: https://bugs.llvm.org/show_bug.cgi?id=40067. Reviewers: jhenderson, ruiu, rnk, fjricci Reviewed By: jhenderson Subscribers: rupprecht, llvm-commits Differential Revision: https://reviews.llvm.org/D56635 llvm-svn: 351043
* Remove TypeBuilder.h, and fix the few locations using it.James Y Knight2019-01-132-39/+0
| | | | | | | | | | | | | | This shortcut mechanism for creating types was added 10 years ago, but has seen almost no uptake since then, neither internally nor in external projects. The very small number of characters saved by using it does not seem worth the mental overhead of an additional type-creation API, so, delete it. Differential Revision: https://reviews.llvm.org/D56573 llvm-svn: 351020
* [llvm-symbolizer] Add -exe, -e as aliases to -objDmitry Venikov2019-01-111-1/+1
| | | | | | | | | | | | | | Summary: Provides -exe, -e as aliases to -obj. Motivation: https://bugs.llvm.org/show_bug.cgi?id=40071 Reviewers: ruiu, rnk, fjricci, jhenderson Reviewed By: jhenderson Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D56580 llvm-svn: 350925
* [Docs] fix typo, adjust text orderSanjay Patel2019-01-101-5/+6
| | | | llvm-svn: 350846
* [Docs] add note to avoid 'errno' for better vectorization (PR40265)Sanjay Patel2019-01-101-0/+4
| | | | | | | This is a partial fix for the documentation improvements requested in: https://bugs.llvm.org/show_bug.cgi?id=40265 llvm-svn: 350845
* [llvm-symbolizer] Add -p as alias to -pretty-printDmitry Venikov2019-01-101-1/+1
| | | | | | | | | | | | | | Summary: Provides -p as a short alias for -pretty-print. Motivation: https://bugs.llvm.org/show_bug.cgi?id=40076 Reviewers: samsonov, khemant, ruiu, rnk, fjricci, jhenderson Reviewed By: jhenderson Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D56542 llvm-svn: 350832
* [llvm-profdata] add value-cutoff functionality in show commandRong Xu2019-01-081-1/+11
| | | | | | | | | | | | | This patch improves llvm-profdata show command: (1) add -value-cutoff=<N> option: Show only those functions whose max count values are greater or equal to N. (2) add -list-below-cutoff option: Only output names of functions whose max count value are below the cutoff. (3) formats value-profile counts and prints out percentage. Differential Revision: https://reviews.llvm.org/D56342 llvm-svn: 350673
* [PGO] Revert r350579 to fix commit message.Rong Xu2019-01-081-11/+1
| | | | | | Will re-commit it using the correct commit message. llvm-svn: 350670
* [PGO] Use SourceFileName rather module name in PGOFuncNameRong Xu2019-01-071-1/+11
| | | | | | | | | | In LTO or Thin-lto mode (though linker plugin), the module names are of temp file names which are different for different compilations. Using SourceFileName avoids the issue. This should not change any functionality for current PGO as all the current callers of getPGOFuncName() is before LTO. llvm-svn: 350579
* Fix typo: "with he MODULE" -> "with the MODULE"Mark Searles2019-01-041-1/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D56302 llvm-svn: 350400
* Python compat - no explicit reference to Python versionSerge Guelton2019-01-031-1/+1
| | | | | | | | Update documentation and shebang. Differential Revision: https://reviews.llvm.org/D56252 llvm-svn: 350327
* Python compat - print statementSerge Guelton2019-01-031-4/+5
| | | | | | | | | Make sure all print statements are compatible with Python 2 and Python3 using the `from __future__ import print_function` statement. Differential Revision: https://reviews.llvm.org/D56249 llvm-svn: 350307
* [AMDGPU][MC][DOC] Updated AMD GPU assembler description.Dmitry Preobrazhensky2018-12-288-2049/+2050
| | | | | | | | Minor bugfixing and improvements. See bug 36572: https://bugs.llvm.org/show_bug.cgi?id=36572 llvm-svn: 350120
* manpages: Update the URL for httpsSylvestre Ledru2018-12-261-1/+1
| | | | llvm-svn: 350077
* ReleaseNotes: X86 Target: bdver2 sched model was added (D52779)Roman Lebedev2018-12-241-1/+2
| | | | llvm-svn: 350053
* ReleaseNotes: Document removal of add_llvm_loadable_module CMake macroTom Stellard2018-12-211-0/+5
| | | | | | This was removed in r349839. llvm-svn: 349921
* cmake: Remove add_llvm_loadable_module()Tom Stellard2018-12-202-3/+3
| | | | | | | | | | | | | | | | | Summary: This function is very similar to add_llvm_library(), so this patch merges it into add_llvm_library() and replaces all calls to add_llvm_loadable_module(lib ...) with add_llvm_library(lib MODULE ...) Reviewers: philip.pfaffe, beanz, chandlerc Reviewed By: philip.pfaffe Subscribers: chapuni, mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D51748 llvm-svn: 349839
* Introduce llvm.loop.parallel_accesses and llvm.access.group metadata.Michael Kruse2018-12-201-51/+81
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current llvm.mem.parallel_loop_access metadata has a problem in that it uses LoopIDs. LoopID unfortunately is not loop identifier. It is neither unique (there's even a regression test assigning the some LoopID to multiple loops; can otherwise happen if passes such as LoopVersioning make copies of entire loops) nor persistent (every time a property is removed/added from a LoopID's MDNode, it will also receive a new LoopID; this happens e.g. when calling Loop::setLoopAlreadyUnrolled()). Since most loop transformation passes change the loop attributes (even if it just to mark that a loop should not be processed again as llvm.loop.isvectorized does, for the versioned and unversioned loop), the parallel access information is lost for any subsequent pass. This patch unlinks LoopIDs and parallel accesses. llvm.mem.parallel_loop_access metadata on instruction is replaced by llvm.access.group metadata. llvm.access.group points to a distinct MDNode with no operands (avoiding the problem to ever need to add/remove operands), called "access group". Alternatively, it can point to a list of access groups. The LoopID then has an attribute llvm.loop.parallel_accesses with all the access groups that are parallel (no dependencies carries by this loop). This intentionally avoid any kind of "ID". Loops that are clones/have their attributes modifies retain the llvm.loop.parallel_accesses attribute. Access instructions that a cloned point to the same access group. It is not necessary for each access to have it's own "ID" MDNode, but those memory access instructions with the same behavior can be grouped together. The behavior of llvm.mem.parallel_loop_access is not changed by this patch, but should be considered deprecated. Differential Revision: https://reviews.llvm.org/D52116 llvm-svn: 349725
* Add llvm-objdump man pageEd Maste2018-12-191-0/+197
| | | | | | Differential Revision: https://reviews.llvm.org/D54864 llvm-svn: 349595
* [docs] Improve HowToCrossCompilerBuiltinsOnArmPeter Smith2018-12-181-51/+140
| | | | | | | | | | | | | | | | | | | | | | Some recent experience on llvm-dev pointed out some errors in the document: - Assumption of ninja - Use of --march rather than -march - Problems with host include files when a multiarch setup was used - Insufficient target information passed to assembler - Instructions on using the cmake cache file BaremetalARM.cmake were incomplete There was also insufficient guidance on what to do when various stages failed due to misconfiguration or missing steps. Summary of changes: - Fixed problems above - Added a troubleshooting section with common errors. - Cleared up one "at time of writing" that is no longer a problem. Differential Revision: https://reviews.llvm.org/D55709 llvm-svn: 349477
* [FileCheck] Annotate input dump (1/7)Joel E. Denny2018-12-181-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Extend FileCheck to dump its input annotated with FileCheck's diagnostics: errors, good matches if -v, and additional information if -vv. The goal is to make it easier to visualize FileCheck's matching behavior when debugging. Each patch in this series implements input annotations for a particular category of FileCheck diagnostics. While the first few patches alone are somewhat useful, the annotations become much more useful as later patches implement annotations for -v and -vv diagnostics, which show the matching behavior leading up to the error. This first patch implements boilerplate plus input annotations for error diagnostics reporting that no matches were found for a directive. These annotations mark the search ranges of the failed directives. Instead of using the usual `^~~`, which is used by later patches for good matches, these annotations use `X~~` so that this category of errors is visually distinct. For example: ``` $ FileCheck -dump-input=help The following description was requested by -dump-input=help to explain the input annotations printed by -dump-input=always and -dump-input=fail: - L: labels line number L of the input file - T:L labels the match result for a pattern of type T from line L of the check file - X~~ marks search range when no match is found - colors error If you are not seeing color above or in input dumps, try: -color $ FileCheck -v -dump-input=always check1 < input1 |& sed -n '/^Input file/,$p' Input file: <stdin> Check file: check1 -dump-input=help describes the format of the following dump. Full input was: <<<<<< 1: ; abc def 2: ; ghI jkl next:3 X~~~~~~~~ error: no match found >>>>>> $ cat check1 CHECK: abc CHECK-SAME: def CHECK-NEXT: ghi CHECK-SAME: jkl $ cat input1 ; abc def ; ghI jkl ``` Some additional details related to the boilerplate: * Enabling: The annotated input dump is enabled by `-dump-input`, which can also be set via the `FILECHECK_OPTS` environment variable. Accepted values are `help`, `always`, `fail`, or `never`. As shown above, `help` describes the format of the dump. `always` is helpful when you want to investigate a successful FileCheck run, perhaps for an unexpected pass. `-dump-input-on-failure` and `FILECHECK_DUMP_INPUT_ON_FAILURE` remain as a deprecated alias for `-dump-input=fail`. * Diagnostics: The usual diagnostics are not suppressed in this mode and are printed first. For brevity in the example above, I've omitted them using a sed command. Sometimes they're perfectly sufficient, and then they make debugging quicker than if you were forced to hunt through a dump of long input looking for the error. If you think they'll get in the way sometimes, keep in mind that it's pretty easy to grep for the start of the input dump, which is `<<<`. * Colored Annotations: The annotated input is colored if colors are enabled (enabling colors can be forced using -color). For example, errors are red. However, as in the above example, colors are not vital to reading the annotations. I don't know how to test color in the output, so any hints here would be appreciated. Reviewed By: george.karpenkov, zturner, probinson Differential Revision: https://reviews.llvm.org/D52999 llvm-svn: 349418
* [AMDGPU][MC][DOC] A fix for build failure in r349370Dmitry Preobrazhensky2018-12-1722-61/+61
| | | | llvm-svn: 349375
* [AMDGPU][MC][DOC] A fix for build failure in r349368Dmitry Preobrazhensky2018-12-171-2/+0
| | | | llvm-svn: 349370
* [AMDGPU][MC][DOC] Updated AMD GPU assembler descriptionDmitry Preobrazhensky2018-12-17279-5600/+12955
| | | | | | | | Stage 2: added detailed description of operands See bug 36572: https://bugs.llvm.org/show_bug.cgi?id=36572 llvm-svn: 349368
* Use backquotes to avoid a sphinx unexpected error:Sylvestre Ledru2018-12-161-1/+1
| | | | | | Unknown target name: "bootstrap". llvm-svn: 349301
* Document the usage of BOOTSTRAP_XXX with stage2 buildsSylvestre Ledru2018-12-161-0/+9
| | | | llvm-svn: 349299
* [docs] Use correct ending quotes.Michael Kruse2018-12-121-1/+1
| | | | llvm-svn: 348947
* [Unroll/UnrollAndJam/Vectorizer/Distribute] Add followup loop attributes.Michael Kruse2018-12-124-0/+570
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When multiple loop transformation are defined in a loop's metadata, their order of execution is defined by the order of their respective passes in the pass pipeline. For instance, e.g. #pragma clang loop unroll_and_jam(enable) #pragma clang loop distribute(enable) is the same as #pragma clang loop distribute(enable) #pragma clang loop unroll_and_jam(enable) and will try to loop-distribute before Unroll-And-Jam because the LoopDistribute pass is scheduled after UnrollAndJam pass. UnrollAndJamPass only supports one inner loop, i.e. it will necessarily fail after loop distribution. It is not possible to specify another execution order. Also,t the order of passes in the pipeline is subject to change between versions of LLVM, optimization options and which pass manager is used. This patch adds 'followup' attributes to various loop transformation passes. These attributes define which attributes the resulting loop of a transformation should have. For instance, !0 = !{!0, !1, !2} !1 = !{!"llvm.loop.unroll_and_jam.enable"} !2 = !{!"llvm.loop.unroll_and_jam.followup_inner", !3} !3 = !{!"llvm.loop.distribute.enable"} defines a loop ID (!0) to be unrolled-and-jammed (!1) and then the attribute !3 to be added to the jammed inner loop, which contains the instruction to distribute the inner loop. Currently, in both pass managers, pass execution is in a fixed order and UnrollAndJamPass will not execute again after LoopDistribute. We hope to fix this in the future by allowing pass managers to run passes until a fixpoint is reached, use Polly to perform these transformations, or add a loop transformation pass which takes the order issue into account. For mandatory/forced transformations (e.g. by having been declared by #pragma omp simd), the user must be notified when a transformation could not be performed. It is not possible that the responsible pass emits such a warning because the transformation might be 'hidden' in a followup attribute when it is executed, or it is not present in the pipeline at all. For this reason, this patche introduces a WarnMissedTransformations pass, to warn about orphaned transformations. Since this changes the user-visible diagnostic message when a transformation is applied, two test cases in the clang repository need to be updated. To ensure that no other transformation is executed before the intended one, the attribute `llvm.loop.disable_nonforced` can be added which should disable transformation heuristics before the intended transformation is applied. E.g. it would be surprising if a loop is distributed before a #pragma unroll_and_jam is applied. With more supported code transformations (loop fusion, interchange, stripmining, offloading, etc.), transformations can be used as building blocks for more complex transformations (e.g. stripmining+stripmining+interchange -> tiling). Reviewed By: hfinkel, dmgreen Differential Revision: https://reviews.llvm.org/D49281 Differential Revision: https://reviews.llvm.org/D55288 llvm-svn: 348944
* [Intrinsic] Signed Fixed Point Multiplication IntrinsicLeonard Chan2018-12-121-0/+70
| | | | | | | | | | | | Add an intrinsic that takes 2 signed integers with the scale of them provided as the third argument and performs fixed point multiplication on them. This is a part of implementing fixed point arithmetic in clang where some of the more complex operations will be implemented as intrinsics. Differential Revision: https://reviews.llvm.org/D54719 llvm-svn: 348912
* [docs] Add the new Objective-C ARC intrinsics to the LangRef.Erik Pilkington2018-12-101-0/+260
| | | | | | | These were added in r348441. This mostly just points to the clang documentation to describe the intended semantics of each intrinsic. llvm-svn: 348782
* Introduce llvm.experimental.widenable_condition intrinsicMax Kazantsev2018-12-071-0/+139
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch introduces a new instinsic `@llvm.experimental.widenable_condition` that allows explicit representation for guards. It is an alternative to using `@llvm.experimental.guard` intrinsic that does not contain implicit control flow. We keep finding places where `@llvm.experimental.guard` is not supported or treated too conservatively, and there are 2 reasons to that: - `@llvm.experimental.guard` has memory write side effect to model implicit control flow, and this sometimes confuses passes and analyzes that work with memory; - Not all passes and analysis are aware of the semantics of guards. These passes treat them as regular throwing call and have no idea that the condition of guard may be used to prove something. One well-known place which had caused us troubles in the past is explicit loop iteration count calculation in SCEV. Another example is new loop unswitching which is not aware of guards. Whenever a new pass appears, we potentially have this problem there. Rather than go and fix all these places (and commit to keep track of them and add support in future), it seems more reasonable to leverage the existing optimizer's logic as much as possible. The only significant difference between guards and regular explicit branches is that guard's condition can be widened. It means that a guard contains (explicitly or implicitly) a `deopt` block successor, and it is always legal to go there no matter what the guard condition is. The other successor is a guarded block, and it is only legal to go there if the condition is true. This patch introduces a new explicit form of guards alternative to `@llvm.experimental.guard` intrinsic. Now a widenable guard can be represented in the CFG explicitly like this: %widenable_condition = call i1 @llvm.experimental.widenable.condition() %new_condition = and i1 %cond, %widenable_condition br i1 %new_condition, label %guarded, label %deopt guarded: ; Guarded instructions deopt: call type @llvm.experimental.deoptimize(<args...>) [ "deopt"(<deopt_args...>) ] The new intrinsic `@llvm.experimental.widenable.condition` has semantics of an `undef`, but the intrinsic prevents the optimizer from folding it early. This form should exploit all optimization boons provided to `br` instuction, and it still can be widened by replacing the result of `@llvm.experimental.widenable.condition()` with `and` with any arbitrary boolean value (as long as the branch that is taken when it is `false` has a deopt and has no side-effects). For more motivation, please check llvm-dev discussion "[llvm-dev] Giving up using implicit control flow in guards". This patch introduces this new intrinsic with respective LangRef changes and a pass that converts old-style guards (expressed as intrinsics) into the new form. The naming discussion is still ungoing. Merging this to unblock further items. We can later change the name of this intrinsic. Reviewed By: reames, fedor.sergeev, sanjoy Differential Revision: https://reviews.llvm.org/D51207 llvm-svn: 348593
* HowToBuildWithPGO.rst: Fix a few details in the manual stepsHans Wennborg2018-12-051-3/+3
| | | | | | Differential revision: https://reviews.llvm.org/D55268 llvm-svn: 348342
* MIR: Add method to stop after specific runs of passesMatt Arsenault2018-12-041-0/+5
| | | | | | | | | | Currently if you use -{start,stop}-{before,after}, it picks the first instance with the matching pass name. If you run the same pass multiple times, there's no way to distinguish them. Allow specifying a run index wih ,N to specify which you mean. llvm-svn: 348285
* [docs][AtomicExpandPass] Document the alternate lowering strategy for ↵Alex Bradbury2018-11-301-2/+18
| | | | | | | | | | | | | | | | | | | | part-word atomicrmw/cmpxchg D47882, D48130 and D48131 introduce a new lowering strategy for part-word atomicrmw/cmpxchg and uses it to lower these operations for the RISC-V target. Rather than having AtomicExpandPass produce the LL/SC loop in the IR level, it instead calculates the necessary mask values and inserts a target-specific intrinsic, which is lowered at a much later stage (after register allocation). This ensures that architecture-specific restrictions for forward-progress in LL/SC loops can be guaranteed. This patch documents this new AtomicExpandPass functionality. See the previous llvm-dev RFC for more info <http://lists.llvm.org/pipermail/llvm-dev/2018-June/123993.html>. Differential Revision: https://reviews.llvm.org/D52234 llvm-svn: 347971
* [clang][slh] add attribute for speculative load hardeningZola Bridges2018-11-271-13/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Resubmit this with no changes because I think the build was broken by a different diff. ----- The prior diff had to be reverted because there were two tests that failed. I updated the two tests in this diff clang/test/Misc/pragma-attribute-supported-attributes-list.test clang/test/SemaCXX/attr-speculative-load-hardening.cpp ----- Summary from Previous Diff (Still Accurate) ----- LLVM IR already has an attribute for speculative_load_hardening. Before this commit, when a user passed the -mspeculative-load-hardening flag to Clang, every function would have this attribute added to it. This Clang attribute will allow users to opt into SLH on a function by function basis. This can be applied to functions and Objective C methods. Reviewers: chandlerc, echristo, kristof.beyls, aaron.ballman Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D54915 llvm-svn: 347701
OpenPOWER on IntegriCloud