summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Support
Commit message (Collapse)AuthorAgeFilesLines
...
* [Support] Remove unused raw_ostream::handle whose anchor role was superseded ↵Fangrui Song2018-06-022-4/+1
| | | | | | by anchor() llvm-svn: 333817
* Move some function declarations out of WindowsSupport.hZachary Turner2018-06-016-14/+5
| | | | | | | | | | | | | | | | | | The idea behind WindowsSupport.h is that it's in the source directory so that windows.h'isms don't leak out into the larger LLVM project. To that end, any symbol that references a symbol from windows.h must be in this private header, and not in a public header. However, we had some useful utility functions in WindowsSupport.h which have no dependency on the Windows API, but still only make sense on Windows. Those functions should be usable outside of Support since there is no risk of causing a windows.h leak. Although this introduces some preprocessor logic in some header files, It's not too egregious and it's better than the alternative of duplicating a ton of code. Differential Revision: https://reviews.llvm.org/D47662 llvm-svn: 333798
* [ADT] Make escaping fn conform to coding guidelinesJonas Devlieghere2018-05-311-2/+2
| | | | | | | | As noted by Adrian on llvm-commits, PrintHTMLEscaped and PrintEscaped in StringExtras did not conform to the LLVM coding guidelines. This commit rectifies that. llvm-svn: 333669
* [dsymutil] Escape HTML special characters in plist.Jonas Devlieghere2018-05-301-0/+17
| | | | | | | | | | When printing string in the Plist, we weren't escaping the characters which lead to invalid XML. This patch adds the escape logic to StringExtras. rdar://39785334 llvm-svn: 333565
* Revert commit 333506Serge Pavlov2018-05-305-12/+36
| | | | | | | It looks like this commit is responsible for the fail: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-autoconf/builds/24382. llvm-svn: 333518
* Use uniform mechanism for OOM errors handlingSerge Pavlov2018-05-305-36/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a recommit of r333390, which was reverted in r333395, because it caused cyclic dependency when building shared library `LLVMDemangle.so`. In this commit `ItaniumDemangler.cpp` was not changed. The original commit message is below. In r325551 many calls of malloc/calloc/realloc were replaces with calls of their safe counterparts defined in the namespace llvm. There functions generate crash if memory cannot be allocated, such behavior facilitates handling of out of memory errors on Windows. If the result of *alloc function were checked for success, the function was not replaced with the safe variant. In these cases the calling function made the error handling, like: T *NewElts = static_cast<T*>(malloc(NewCapacity*sizeof(T))); if (NewElts == nullptr) report_bad_alloc_error("Allocation of SmallVector element failed."); Actually knowledge about the function where OOM occurred is useless. Moreover having a single entry point for OOM handling is convenient for investigation of memory problems. This change removes custom OOM errors handling and replaces them with calls to functions `llvm::safe_*alloc`. Declarations of `safe_*alloc` are moved to a separate include file, to avoid cyclic dependency in SmallVector.h Differential Revision: https://reviews.llvm.org/D47440 llvm-svn: 333506
* Reverted commits 333390, 333391 and 333394Serge Pavlov2018-05-295-12/+36
| | | | | | Build of shared library LLVMDemangle.so fails due to dependency problem. llvm-svn: 333395
* Use uniform mechanism for OOM errors handlingSerge Pavlov2018-05-295-36/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | In r325551 many calls of malloc/calloc/realloc were replaces with calls of their safe counterparts defined in the namespace llvm. There functions generate crash if memory cannot be allocated, such behavior facilitates handling of out of memory errors on Windows. If the result of *alloc function were checked for success, the function was not replaced with the safe variant. In these cases the calling function made the error handling, like: T *NewElts = static_cast<T*>(malloc(NewCapacity*sizeof(T))); if (NewElts == nullptr) report_bad_alloc_error("Allocation of SmallVector element failed."); Actually knowledge about the function where OOM occurred is useless. Moreover having a single entry point for OOM handling is convenient for investigation of memory problems. This change removes custom OOM errors handling and replaces them with calls to functions `llvm::safe_*alloc`. Declarations of `safe_*alloc` are moved to a separate include file, to avoid cyclic dependency in SmallVector.h Differential Revision: https://reviews.llvm.org/D47440 llvm-svn: 333390
* [Support] Avoid normalization in sys::getDefaultTargetTriplePetr Hosek2018-05-252-2/+2
| | | | | | | | | | | | | | | | | | | | | | The return value of sys::getDefaultTargetTriple, which is derived from -DLLVM_DEFAULT_TRIPLE, is used to construct tool names, default target, and in the future also to control the search path directly; as such it should be used textually, without interpretation by LLVM. Normalization of this value may lead to unexpected results, for example if we configure LLVM with -DLLVM_DEFAULT_TARGET_TRIPLE=x86_64-linux-gnu, normalization will transform that value to x86_64--linux-gnu. Driver will use that value to search for tools prefixed with x86_64--linux-gnu- which may be confusing. This is also inconsistent with the behavior of the --target flag which is taken as-is without any normalization and overrides the value of LLVM_DEFAULT_TARGET_TRIPLE. Users of sys::getDefaultTargetTriple already perform their own normalization as needed, so this change shouldn't impact existing logic. Differential Revision: https://reviews.llvm.org/D47153 llvm-svn: 333307
* [x86] invpcid LLVM intrinsicGabor Buella2018-05-251-0/+1
| | | | | | | | | | | | | | | Re-add the feature flag for invpcid, which was removed in r294561. Add an intrinsic, which always uses a 32 bit integer as first argument, while the instruction actually uses a 64 bit register in 64 bit mode for the INVPCID_TYPE argument. Reviewers: craig.topper Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D47141 llvm-svn: 333255
* [Support] Move header to WithColor headerJonas Devlieghere2018-05-241-1/+0
| | | | | | | Forgot to move the CommandLine.h include form the implementation to the header and didn't notice the failure with my local modules build. llvm-svn: 333177
* [Support] Add color cl category.Jonas Devlieghere2018-05-241-2/+4
| | | | | | | | | This commit adds a color category so tools can document this option and enables it for dwarfdump and dsymuttil. rdar://problem/40498996 llvm-svn: 333176
* Revert 332750, llvm part (see comment on D46910).Nico Weber2018-05-202-2/+2
| | | | llvm-svn: 332823
* [Support] Avoid normalization in sys::getDefaultTargetTriplePetr Hosek2018-05-182-2/+2
| | | | | | | | | | | | | | | | | | | | | | The return value of sys::getDefaultTargetTriple, which is derived from -DLLVM_DEFAULT_TRIPLE, is used to construct tool names, default target, and in the future also to control the search path directly; as such it should be used textually, without interpretation by LLVM. Normalization of this value may lead to unexpected results, for example if we configure LLVM with -DLLVM_DEFAULT_TARGET_TRIPLE=x86_64-linux-gnu, normalization will transform that value to x86_64--linux-gnu. Driver will use that value to search for tools prefixed with x86_64--linux-gnu- which may be confusing. This is also inconsistent with the behavior of the --target flag which is taken as-is without any normalization and overrides the value of LLVM_DEFAULT_TARGET_TRIPLE. Users of sys::getDefaultTargetTriple already perform their own normalization as needed, so this change shouldn't impact existing logic. Differential Revision: https://reviews.llvm.org/D46910 llvm-svn: 332750
* [X86][CET] Changing -fcf-protection behavior to comply with gcc (LLVM part)Alexander Ivchenko2018-05-181-2/+0
| | | | | | | | | | | | | | | | | | | | This patch aims to match the changes introduced in gcc by https://gcc.gnu.org/ml/gcc-cvs/2018-04/msg00534.html. The IBT feature definition is removed, with the IBT instructions being freely available on all X86 targets. The shadow stack instructions are also being made freely available, and the use of all these CET instructions is controlled by the module flags derived from the -fcf-protection clang option. The hasSHSTK option remains since clang uses it to determine availability of shadow stack instruction intrinsics, but it is no longer directly used. Comes with a clang patch (D46881). Patch by mike.dvoretsky Differential Revision: https://reviews.llvm.org/D46882 llvm-svn: 332705
* Support: Add a raw_ostream::write_zeros() function. NFCI.Peter Collingbourne2018-05-171-14/+26
| | | | | | | | | | This will eventually replace MCObjectWriter::WriteZeros. Part of PR37466. Differential Revision: https://reviews.llvm.org/D47033 llvm-svn: 332675
* Revert 332508 as it caused problems in the clang test suite.Greg Clayton2018-05-161-4/+0
| | | | llvm-svn: 332555
* Fix llvm::sys::path::remove_dots() to return "." instead of an empty path.Greg Clayton2018-05-161-0/+4
| | | | | | Differential Revision: https://reviews.llvm.org/D46887 llvm-svn: 332508
* [Timers] TimerGroup: add constructor from StringMap<TimeRecord>Roman Lebedev2018-05-161-0/+9
| | | | | | | | | | | | | | | | Summary: This is needed for the continuation of D46504, to be able to store the timings. Reviewers: george.karpenkov, NoQ, alexfh, sbenza Reviewed By: alexfh Subscribers: llvm-commits, cfe-commits Differential Revision: https://reviews.llvm.org/D46939 llvm-svn: 332506
* [Timers] TimerGroup: make printJSONValues() method publicRoman Lebedev2018-05-161-0/+2
| | | | | | | | | | | | | | | | Summary: This is needed for the continuation of D46504, to be able to store the timings. Reviewers: george.karpenkov, NoQ, alexfh, sbenza Reviewed By: alexfh Subscribers: llvm-commits, cfe-commits Differential Revision: https://reviews.llvm.org/D46938 llvm-svn: 332505
* [Timers] TimerGroup::printJSONValue(): print doubles with no precision lossRoman Lebedev2018-05-161-3/+7
| | | | | | | | | | | | | | | | Summary: Although this is not stricly required, i would very much prefer not to have known random precision losses along the way. Reviewers: george.karpenkov, NoQ, alexfh, sbenza Reviewed By: george.karpenkov Subscribers: llvm-commits, cfe-commits Differential Revision: https://reviews.llvm.org/D46937 llvm-svn: 332504
* [Timers] TimerGroup::printJSONValues(): print mem timer with .mem suffixRoman Lebedev2018-05-161-1/+1
| | | | | | | | | | | | | | Summary: We have just used `.sys` suffix for the previous timer, this is clearly a typo Reviewers: george.karpenkov, NoQ, alexfh, sbenza Reviewed By: alexfh Subscribers: llvm-commits, cfe-commits Differential Revision: https://reviews.llvm.org/D46936 llvm-svn: 332503
* Signal handling should be signal-safeJF Bastien2018-05-163-84/+209
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Before this patch, signal handling wasn't signal safe. This leads to real-world crashes. It used ManagedStatic inside of signals, this can allocate and can lead to unexpected state when a signal occurs during llvm_shutdown (because llvm_shutdown destroys the ManagedStatic). It also used cl::opt without custom backing storage. Some de-allocation was performed as well. Acquiring a lock in a signal handler is also a great way to deadlock. We can't just disable signals on llvm_shutdown because the signals might do useful work during that shutdown. We also can't just disable llvm_shutdown for programs (instead of library uses of clang) because we'd have to then mark the pointers as not leaked and make sure all the ManagedStatic uses are OK to leak and remain so. Move all of the code to lock-free datastructures instead, and avoid having any of them in an inconsistent state. I'm not trying to be fancy, I'm not using any explicit memory order because this code isn't hot. The only purpose of the atomics is to guarantee that a signal firing on the same or a different thread doesn't see an inconsistent state and crash. In some cases we might miss some state (for example, we might fail to delete a temporary file), but that's fine. Note that I haven't touched any of the backtrace support despite it not technically being totally signal-safe. When that code is called we know something bad is up and we don't expect to continue execution, so calling something that e.g. sets errno is the least of our problems. A similar patch should be applied to lib/Support/Windows/Signals.inc, but that can be done separately. Fix r332428 which I reverted in r332429. I originally used double-wide CAS because I was lazy, but some platforms use a runtime function for that which thankfully failed to link (it would have been bad for signal handlers otherwise). I use a separate flag to guard the data instead. <rdar://problem/28010281> Reviewers: dexonsmith Subscribers: steven_wu, llvm-commits llvm-svn: 332496
* [Unix] Indent ChangeStd{in,out}ToBinary.Fangrui Song2018-05-161-4/+4
| | | | llvm-svn: 332432
* Revert "Signal handling should be signal-safe"JF Bastien2018-05-163-199/+87
| | | | | | Some bots don't have double-pointer width compare-and-exchange. Revert for now.q llvm-svn: 332429
* Signal handling should be signal-safeJF Bastien2018-05-163-87/+199
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Before this patch, signal handling wasn't signal safe. This leads to real-world crashes. It used ManagedStatic inside of signals, this can allocate and can lead to unexpected state when a signal occurs during llvm_shutdown (because llvm_shutdown destroys the ManagedStatic). It also used cl::opt without custom backing storage. Some de-allocation was performed as well. Acquiring a lock in a signal handler is also a great way to deadlock. We can't just disable signals on llvm_shutdown because the signals might do useful work during that shutdown. We also can't just disable llvm_shutdown for programs (instead of library uses of clang) because we'd have to then mark the pointers as not leaked and make sure all the ManagedStatic uses are OK to leak and remain so. Move all of the code to lock-free datastructures instead, and avoid having any of them in an inconsistent state. I'm not trying to be fancy, I'm not using any explicit memory order because this code isn't hot. The only purpose of the atomics is to guarantee that a signal firing on the same or a different thread doesn't see an inconsistent state and crash. In some cases we might miss some state (for example, we might fail to delete a temporary file), but that's fine. Note that I haven't touched any of the backtrace support despite it not technically being totally signal-safe. When that code is called we know something bad is up and we don't expect to continue execution, so calling something that e.g. sets errno is the least of our problems. A similar patch should be applied to lib/Support/Windows/Signals.inc, but that can be done separately. <rdar://problem/28010281> Reviewers: dexonsmith Subscribers: aheejin, llvm-commits Differential Revision: https://reviews.llvm.org/D46858 llvm-svn: 332428
* [NFC] pull a function into its own lambdaJF Bastien2018-05-151-19/+21
| | | | | | | | | As requested in D46858, pulling this function into its own lambda makes it easier to read that part of the code and reason as to what's going on because the scope it can be called from is extremely limited. We want to keep it as a function because it's called from the two subsequent lines. llvm-svn: 332325
* [NFC] Update commentsJF Bastien2018-05-152-31/+30
| | | | | | Don't prepend function or data name before each comment. Split into its own NFC patch as requested in D46858. llvm-svn: 332323
* [CommandLine] Error message for incorrect PositionalEatArgs usageKeno Fischer2018-05-141-9/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: bugpoint has several options specified as `PositionalEatArgs` to pass options through to the underlying tool, e.g. `-tool-args`. The `-help` message suggests the usage is: `-tool-args=<string>`. However, this is misleading, because that's not how these arguments work. Rather than taking a value, the option consumes all positional arguments until the next recognized option (or all arguments if `--` is specified at some point). To make this slightly clearer, instead print the help as: ``` -tool-args <string>... - <tool arguments>... ``` Additionally, add an error if the user attempts to use a `PositionalEatArgs` argument with a value, instead of silently ignoring it. Example: ``` ./bin/bugpoint -tool-args=-mpcu=skylake-avx512 bugpoint: for the -tool-args option: This argument does not take a value. Instead, it consumes any positional arguments until the next recognized option. ``` Reviewed By: aprantl Differential Revision: https://reviews.llvm.org/D46787 llvm-svn: 332311
* Rename DEBUG macro to LLVM_DEBUG.Nicola Zaghen2018-05-146-116/+127
| | | | | | | | | | | | | | | | The DEBUG() macro is very generic so it might clash with other projects. The renaming was done as follows: - git grep -l 'DEBUG' | xargs sed -i 's/\bDEBUG\s\?(/LLVM_DEBUG(/g' - git diff -U0 master | ../clang/tools/clang-format/clang-format-diff.py -i -p1 -style LLVM - Manual change to APInt - Manually chage DOCS as regex doesn't match it. In the transition period the DEBUG() macro is still present and aliased to the LLVM_DEBUG() one. Differential Revision: https://reviews.llvm.org/D43624 llvm-svn: 332240
* [NFC] Remove inaccurate commentJF Bastien2018-05-121-3/+0
| | | | | | | | | | | | | | | Summary: r271558 moved getManagedStaticMutex's mutex from a function-local static to using call_once, but left a comment added in r211424. That comment is now erroneous, remove it. Reviewers: zturner, chandlerc Subscribers: aheejin, llvm-commits Differential Revision: https://reviews.llvm.org/D46784 llvm-svn: 332175
* Remove unused SyncExecutor and make it clearer that the whole file is only ↵Nico Weber2018-05-111-14/+5
| | | | | | used if LLVM_ENABLE_THREADS llvm-svn: 332098
* [APFloat] Set losesInfo on no-op convertSven van Haastregt2018-05-111-1/+3
| | | | | | | | | | | | losesInfo would be left unset when no conversion needs to be done. A caller such as InstCombine's fitsInFPType would then branch on an uninitialized value. Caught using valgrind on an out-of-tree target. Differential Revision: https://reviews.llvm.org/D46645 llvm-svn: 332087
* [Support] Add docs for 'openFileFor{Write,Read}'Brian Gesiak2018-05-111-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Add documentation for the LLVM Support functions `openFileForWrite` and `openFileForRead`. The `openFileForRead` parameter `RealPath`, in particular, I think warranted some explanation. In addition, make the behavior of the functions more consistent across platforms. Prior to this patch, Windows would set or not set the result file descriptor based on the nature of the error, whereas Unix would consistently set it to `-1` if the open failed. Make Windows consistently set it to `-1` as well. Test Plan: 1. `ninja check-llvm` 2. `ninja docs-llvm-html` Reviewers: zturner, rnk, danielmartin, scanon Reviewed By: danielmartin, scanon Subscribers: scanon, danielmartin, llvm-commits Differential Revision: https://reviews.llvm.org/D46499 llvm-svn: 332075
* [X86] ptwrite intrinsicGabor Buella2018-05-101-0/+5
| | | | | | | | | | Reviewers: craig.topper, RKSimon Reviewed By: craig.topper, RKSimon Differential Revision: https://reviews.llvm.org/D46539 llvm-svn: 331961
* APFloat/x87: Fix string conversion for "unnormal" values (pr35860)Pavel Labath2018-05-091-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Unnormal values are a feature of some very old x87 processors. We handle them correctly for the most part -- the only exception was an unnormal value whose significand happened to be zero. In this case the APFloat was still initialized as normal number (category = fcNormal), but a subsequent toString operation would assert because the math would produce nonsensical values for the zero significand. During review, it was decided that the correct way to fix this is to treat all unnormal values as NaNs (as that is what any >=386 processor will do). The issue was discovered because LLDB would crash when trying to print some "long double" values. Reviewers: skatkov, scanon, gottesmm Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D41868 llvm-svn: 331884
* [Support/Path] Make handling of paths like "///" consistentPavel Labath2018-05-091-24/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Various path functions were not treating paths consisting of slashes alone consistently. For example, the iterator-based accessors decomposed the path "///" into two elements: "/" and ".". This is not too bad, but it is different from the behavior specified by posix: ``` A pathname that contains ***at least one non-slash character*** and that ends with one or more trailing slashes shall be resolved as if a single dot character ( '.' ) were appended to the pathname. ``` More importantly, this was different from how we treated the same path in the filename+parent_path functions, which decomposed this path into "." and "". This was completely wrong as it lost the information that this was an absolute path which referred to the root directory. This patch fixes this behavior by making sure all functions treat paths consisting of (back)slashes alone the same way as "/". I.e., the iterator-based functions will just report one component ("/"), and the filename+parent_path will decompose them into "/" and "". A slightly controversial topic here may be the treatment of "//". Posix says that paths beginning with "//" may have special meaning and indeed we have code which parses paths like "//net/foo/bar" specially. However, as we were already not being consistent in parsing the "//" string alone, and any special parsing for it would complicate the code further, I chose to treat it the same way as longer sequences of slashes (which are guaranteed to be the same as "/"). Another slight change of behavior is in the parsing of paths like "//net//". Previously the last component of this path was ".". However, as in our parsing the "//net" part in this path was the same as the "drive" part in "c:\" and the next slash was the "root directory", it made sense to treat "//net//" the same way as "//net/" (i.e., not to add the extra "." component at the end). Reviewers: zturner, rnk, dblaikie, Bigcheese Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D45942 llvm-svn: 331876
* [x86] Introduce the pconfig instructionGabor Buella2018-05-081-0/+12
| | | | | | | | | | Reviewers: craig.topper, zvi Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D46430 llvm-svn: 331739
* Simplify LLVM_ATTRIBUTE_USED call sites.Fangrui Song2018-05-051-8/+3
| | | | llvm-svn: 331599
* Fix include of config.h that was incorrectly changed in r331184Justin Bogner2018-05-031-1/+1
| | | | | | | | | The RWMutex implementation depends on config.h macros (specifically HAVE_PTHREAD_H and HAVE_PTHREAD_RWLOCK_INIT), so we need to be including it and not just llvm-config.h here or we fall back to a much slower implementation. llvm-svn: 331487
* [Support] Support building LLVM for FuchsiaPetr Hosek2018-05-031-0/+3
| | | | | | | | | | These are necessary changes to support building LLVM for Fuchsia. While these are not sufficient to run on Fuchsia, they are still useful when cross-compiling LLVM libraries and runtimes for Fuchsia. Differential Revision: https://reviews.llvm.org/D46345 llvm-svn: 331423
* [X86][AMD][Bulldozer] Fix Bulldozer Model 2 detection.Roman Lebedev2018-05-011-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: I have discovered an issue by accident. ``` $ lscpu Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 8 On-line CPU(s) list: 0-7 Thread(s) per core: 2 Core(s) per socket: 4 Socket(s): 1 NUMA node(s): 1 Vendor ID: AuthenticAMD CPU family: 21 Model: 2 Model name: AMD FX(tm)-8350 Eight-Core Processor Stepping: 0 CPU MHz: 3584.018 CPU max MHz: 4000.0000 CPU min MHz: 1400.0000 BogoMIPS: 8027.22 Virtualization: AMD-V L1d cache: 16K L1i cache: 64K L2 cache: 2048K L3 cache: 8192K NUMA node0 CPU(s): 0-7 Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 popcnt aes xsave avx f16c lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr tbm topoext perfctr_core perfctr_nb cpb hw_pstate vmmcall bmi1 arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold ``` So this is model-2 bulldozer AMD CPU. GCC agrees: ``` $ echo | gcc -E - -march=native -### <...> /usr/lib/gcc/x86_64-linux-gnu/7/cc1 -E -quiet -imultiarch x86_64-linux-gnu - "-march=bdver2" -mmmx -mno-3dnow -msse -msse2 -msse3 -mssse3 -msse4a -mcx16 -msahf -mno-movbe -maes -mno-sha -mpclmul -mpopcnt -mabm -mlwp -mfma -mfma4 -mxop -mbmi -mno-sgx -mno-bmi2 -mtbm -mavx -mno-avx2 -msse4.2 -msse4.1 -mlzcnt -mno-rtm -mno-hle -mno-rdrnd -mf16c -mno-fsgsbase -mno-rdseed -mprfchw -mno-adx -mfxsr -mxsave -mno-xsaveopt -mno-avx512f -mno-avx512er -mno-avx512cd -mno-avx512pf -mno-prefetchwt1 -mno-clflushopt -mno-xsavec -mno-xsaves -mno-avx512dq -mno-avx512bw -mno-avx512vl -mno-avx512ifma -mno-avx512vbmi -mno-avx5124fmaps -mno-avx5124vnniw -mno-clwb -mno-mwaitx -mno-clzero -mno-pku -mno-rdpid --param "l1-cache-size=16" --param "l1-cache-line-size=64" --param "l2-cache-size=2048" "-mtune=bdver2" <...> ``` But clang does not: (look for `bdver1`) ``` $ echo | clang -E - -march=native -### clang version 7.0.0- (trunk) Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/local/bin "/usr/lib/llvm-7/bin/clang" "-cc1" "-triple" "x86_64-pc-linux-gnu" "-E" "-disable-free" "-disable-llvm-verifier" "-discard-value-names" "-main-file-name" "-" "-mrelocation-model" "static" "-mthread-model" "posix" "-mdisable-fp-elim" "-fmath-errno" "-masm-verbose" "-mconstructor-aliases" "-munwind-tables" "-fuse-init-array" "-target-cpu" "bdver1" "-target-feature" "+sse2" "-target-feature" "+cx16" "-target-feature" "+sahf" "-target-feature" "+tbm" "-target-feature" "-avx512ifma" "-target-feature" "-sha" "-target-feature" "-gfni" "-target-feature" "+fma4" "-target-feature" "-vpclmulqdq" "-target-feature" "+prfchw" "-target-feature" "-bmi2" "-target-feature" "-cldemote" "-target-feature" "-fsgsbase" "-target-feature" "-xsavec" "-target-feature" "+popcnt" "-target-feature" "+aes" "-target-feature" "-avx512bitalg" "-target-feature" "-xsaves" "-target-feature" "-avx512er" "-target-feature" "-avx512vnni" "-target-feature" "-avx512vpopcntdq" "-target-feature" "-clwb" "-target-feature" "-avx512f" "-target-feature" "-clzero" "-target-feature" "-pku" "-target-feature" "+mmx" "-target-feature" "+lwp" "-target-feature" "-rdpid" "-target-feature" "+xop" "-target-feature" "-rdseed" "-target-feature" "-waitpkg" "-target-feature" "-ibt" "-target-feature" "+sse4a" "-target-feature" "-avx512bw" "-target-feature" "-clflushopt" "-target-feature" "+xsave" "-target-feature" "-avx512vbmi2" "-target-feature" "-avx512vl" "-target-feature" "-avx512cd" "-target-feature" "+avx" "-target-feature" "-vaes" "-target-feature" "-rtm" "-target-feature" "+fma" "-target-feature" "+bmi" "-target-feature" "-rdrnd" "-target-feature" "-mwaitx" "-target-feature" "+sse4.1" "-target-feature" "+sse4.2" "-target-feature" "-avx2" "-target-feature" "-wbnoinvd" "-target-feature" "+sse" "-target-feature" "+lzcnt" "-target-feature" "+pclmul" "-target-feature" "-prefetchwt1" "-target-feature" "+f16c" "-target-feature" "+ssse3" "-target-feature" "-sgx" "-target-feature" "-shstk" "-target-feature" "+cmov" "-target-feature" "-avx512vbmi" "-target-feature" "-movbe" "-target-feature" "-xsaveopt" "-target-feature" "-avx512dq" "-target-feature" "-adx" "-target-feature" "-avx512pf" "-target-feature" "+sse3" "-dwarf-column-info" "-debugger-tuning=gdb" "-resource-dir" "/usr/lib/llvm-7/lib/clang/7.0.0" "-internal-isystem" "/usr/local/include" "-internal-isystem" "/usr/lib/llvm-7/lib/clang/7.0.0/include" "-internal-externc-isystem" "/usr/include/x86_64-linux-gnu" "-internal-externc-isystem" "/include" "-internal-externc-isystem" "/usr/include" "-fdebug-compilation-dir" "/build/llvm-build-Clang-release" "-ferror-limit" "19" "-fmessage-length" "271" "-fobjc-runtime=gcc" "-fdiagnostics-show-option" "-fcolor-diagnostics" "-o" "-" "-x" "c" "-" ``` So clang, unlike gcc, considers this to be `bdver1`. After some digging, i've come across `getAMDProcessorTypeAndSubtype()` in `Host.cpp`. I have added the following debug printf after the call to that function in `sys::getHostCPUName()`: ``` errs() << "Family " << Family << " Model " << Model << " Type " << Type "\n"; ``` Which produced: ``` Family 21 Model 2 Type 5 ``` Which matches the `lscpu` output. As it was pointed in the review by @craig.topper: >>! In D46314#1084123, @craig.topper wrote: > I dont' think this is right. Here is what I found on wikipedia. https://en.wikipedia.org/wiki/List_of_AMD_CPU_microarchitectures. > > AMD Bulldozer Family 15h - the successor of 10h/K10. Bulldozer is designed for processors in the 10 to 220W category, implementing XOP, FMA4 and CVT16 instruction sets. Orochi was the first design which implemented it. For Bulldozer, CPUID model numbers are 00h and 01h. > AMD Piledriver Family 15h (2nd-gen) - successor to Bulldozer. CPUID model numbers are 02h (earliest "Vishera" Piledrivers) and 10h-1Fh. > AMD Steamroller Family 15h (3rd-gen) - third-generation Bulldozer derived core. CPUID model numbers are 30h-3Fh. > AMD Excavator Family 15h (4th-gen) - fourth-generation Bulldozer derived core. CPUID model numbers are 60h-6Fh, later updated revisions have model numbers 70h-7Fh. > > > So there's a weird exception where model 2 should go with 0x10-0x1f. Though It does not help that the code can't be tested at the moment. With this logical change, the `bdver2` is properly detected. ``` $ echo | /build/llvm-build-Clang-release/bin/clang -E - -march=native -### clang version 7.0.0 (trunk 331249) (llvm/trunk 331256) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /build/llvm-build-Clang-release/bin "/build/llvm-build-Clang-release/bin/clang-7" "-cc1" "-triple" "x86_64-unknown-linux-gnu" "-E" "-disable-free" "-main-file-name" "-" "-mrelocation-model" "static" "-mthread-model" "posix" "-mdisable-fp-elim" "-fmath-errno" "-masm-verbose" "-mconstructor-aliases" "-munwind-tables" "-fuse-init-array" "-target-cpu" "bdver2" "-target-feature" "+sse2" "-target-feature" "+cx16" "-target-feature" "+sahf" "-target-feature" "+tbm" "-target-feature" "-avx512ifma" "-target-feature" "-sha" "-target-feature" "-gfni" "-target-feature" "+fma4" "-target-feature" "-vpclmulqdq" "-target-feature" "+prfchw" "-target-feature" "-bmi2" "-target-feature" "-cldemote" "-target-feature" "-fsgsbase" "-target-feature" "-xsavec" "-target-feature" "+popcnt" "-target-feature" "+aes" "-target-feature" "-avx512bitalg" "-target-feature" "-movdiri" "-target-feature" "-xsaves" "-target-feature" "-avx512er" "-target-feature" "-avx512vnni" "-target-feature" "-avx512vpopcntdq" "-target-feature" "-clwb" "-target-feature" "-avx512f" "-target-feature" "-clzero" "-target-feature" "-pku" "-target-feature" "+mmx" "-target-feature" "+lwp" "-target-feature" "-rdpid" "-target-feature" "+xop" "-target-feature" "-rdseed" "-target-feature" "-waitpkg" "-target-feature" "-movdir64b" "-target-feature" "-ibt" "-target-feature" "+sse4a" "-target-feature" "-avx512bw" "-target-feature" "-clflushopt" "-target-feature" "+xsave" "-target-feature" "-avx512vbmi2" "-target-feature" "-avx512vl" "-target-feature" "-avx512cd" "-target-feature" "+avx" "-target-feature" "-vaes" "-target-feature" "-rtm" "-target-feature" "+fma" "-target-feature" "+bmi" "-target-feature" "-rdrnd" "-target-feature" "-mwaitx" "-target-feature" "+sse4.1" "-target-feature" "+sse4.2" "-target-feature" "-avx2" "-target-feature" "-wbnoinvd" "-target-feature" "+sse" "-target-feature" "+lzcnt" "-target-feature" "+pclmul" "-target-feature" "-prefetchwt1" "-target-feature" "+f16c" "-target-feature" "+ssse3" "-target-feature" "-sgx" "-target-feature" "-shstk" "-target-feature" "+cmov" "-target-feature" "-avx512vbmi" "-target-feature" "-movbe" "-target-feature" "-xsaveopt" "-target-feature" "-avx512dq" "-target-feature" "-adx" "-target-feature" "-avx512pf" "-target-feature" "+sse3" "-dwarf-column-info" "-debugger-tuning=gdb" "-resource-dir" "/build/llvm-build-Clang-release/lib/clang/7.0.0" "-internal-isystem" "/usr/local/include" "-internal-isystem" "/build/llvm-build-Clang-release/lib/clang/7.0.0/include" "-internal-externc-isystem" "/usr/include/x86_64-linux-gnu" "-internal-externc-isystem" "/include" "-internal-externc-isystem" "/usr/include" "-fdebug-compilation-dir" "/build/llvm-build-Clang-release" "-ferror-limit" "19" "-fmessage-length" "271" "-fobjc-runtime=gcc" "-fdiagnostics-show-option" "-fcolor-diagnostics" "-o" "-" "-x" "c" "-" ``` Reviewers: craig.topper, GBuella, RKSimon, asbirlea, echristo, bkramer, spatel, andreadb, GGanesh Reviewed By: craig.topper Subscribers: sdardis, aprantl, arichardson, JDevlieghere, llvm-commits Differential Revision: https://reviews.llvm.org/D46314 llvm-svn: 331294
* Remove @brief commands from doxygen comments, too.Adrian Prantl2018-05-013-66/+66
| | | | | | | | | | | | | | | | | This is a follow-up to r331272. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done https://reviews.llvm.org/D46290 llvm-svn: 331275
* Remove \brief commands from doxygen comments.Adrian Prantl2018-05-0112-20/+20
| | | | | | | | | | | | | | | | We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46290 llvm-svn: 331272
* [X86] movdiri and movdir64b instructionsGabor Buella2018-05-011-0/+2
| | | | | | | | | | Reviewers: spatel, craig.topper, RKSimon Reviewed By: craig.topper, RKSimon Differential Revision: https://reviews.llvm.org/D45983 llvm-svn: 331248
* IWYU for llvm-config.h, removals. Also see r331184.Nico Weber2018-04-301-1/+0
| | | | llvm-svn: 331190
* IWYU for llvm-config.h in llvm, additions.Nico Weber2018-04-3024-13/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | See r331124 for how I made a list of files missing the include. I then ran this Python script: for f in open('filelist.txt'): f = f.strip() fl = open(f).readlines() found = False for i in xrange(len(fl)): p = '#include "llvm/' if not fl[i].startswith(p): continue if fl[i][len(p):] > 'Config': fl.insert(i, '#include "llvm/Config/llvm-config.h"\n') found = True break if not found: print 'not found', f else: open(f, 'w').write(''.join(fl)) and then looked through everything with `svn diff | diffstat -l | xargs -n 1000 gvim -p` and tried to fix include ordering and whatnot. No intended behavior change. llvm-svn: 331184
* Remove a dead #ifdef.Nico Weber2018-04-301-2/+0
| | | | | | | Unix/Threading.inc should never be included on _WIN32. See also https://reviews.llvm.org/D30526#1082292 llvm-svn: 331151
* s/LLVM_ON_WIN32/_WIN32/, llvmNico Weber2018-04-2924-49/+49
| | | | | | | | | | | | | | LLVM_ON_WIN32 is set exactly with MSVC and MinGW (but not Cygwin) in HandleLLVMOptions.cmake, which is where _WIN32 defined too. Just use the default macro instead of a reinvented one. See thread "Replacing LLVM_ON_WIN32 with just _WIN32" on llvm-dev and cfe-dev. No intended behavior change. This moves over all uses of the macro, but doesn't remove the definition of it in (llvm-)config.h yet. llvm-svn: 331127
* [GlobalISel] Reporting rules covered as part of the InstructionSelect's ↵Roman Tereshin2018-04-261-1/+6
| | | | | | | | | | | | | debug-only printing The main goal of this change is to make it much easier to track which rules are actually covered by Testgen'erated regression tests. Reviewers: aemerson, dsanders Differential Revision: https://reviews.llvm.org/D46095 llvm-svn: 330988
OpenPOWER on IntegriCloud