- Feb 14, 2020
-
-
Jenkins CI authored
-
Christopher Ferris authored
Summary: Add a method to set the release to OS value as the system runs, and allow this to be set differently in the primary and the secondary. Also, add a default value to use for primary and secondary. This allows Android to have a default that is different for primary/secondary. Update mallopt to support setting the release to OS value. Reviewers: pcc, cryptoad Reviewed By: cryptoad Subscribers: cryptoad, jfb, #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D74448
-
Sean Fertile authored
In https://reviews.llvm.org/rG8b737688c21a9755cae14cb9343930e0882164ab I switched the condition gating the creation of the descriptor symbol from checking the MCAsmInfo if we need to support descriptors, to if the OS was AIX. Technically the 2 should be interchangeable: if we are targeting AIX then we need to emit XCOFF object files, and the MCAsmInfo must return true for needing function descriptors. This doesn't account for lit test with runsteps that only set the arch. Eg: test/CodeGen/XCore/section-name.ll which when run natively on AIX we end up with a target xcore-ibm-aix and needFunctionDescriptors is false. This patch reverts to using the MCAsmInfo and adds an assert that the target OS must be AIX since that is the only target using the descriptor hook. Differential Revision: https://reviews.llvm.org/D74622
-
Nico Weber authored
-
Nico Weber authored
This is like -fdata-sections, and it's not part of /O2 by default for some reason. In the cmake build, reduces the size of clang.exe from 70,358,016 bytes to 69,982,720 bytes. clang-format.exe goes from 3,703,296 bytes to 3,331,072 bytes. Differential Revision: https://reviews.llvm.org/D74573
-
Austin Kerbow authored
Differential Revision: https://reviews.llvm.org/D74630
-
Evandro Menezes authored
Repeat the build instructions from the top level README in the Getting Started guide.
-
Matt Arsenault authored
The division expansions in AMDGPUCodeGenPrepare can't be relied on for correctness, since they punt to later optimization and possibly legalization in some cases. We still need a way to be able to write tests for the legalizer versions of the expansion. This is mostly for GlobalISel, since the expected optimzations is expecting aren't implemented. The interaction with the flag to expand 64-bit division in the IR is pretty confusing, but these flags have different purposes.
-
Sanjay Patel authored
I updated the prefix and forgot to manually remove the old names as part of rG6071fc57a45.f
-
Sanjay Patel authored
The existing checks were trying to test both CPU-specific codegen and generic codegen with explicit attributes for the various sqrt estimate possibilities, but that was hard to decipher and update (D69989). Instead generate the complete results for various CPUs, and that makes it clear which models have slow/fast sqrt attributes along with all of the other potential diffs (FMA, AVX2, scheduling). Also, explicitly add the function attributes corresponding to whether DAZ/FTZ denorm settings are expected.
-
Matt Arsenault authored
I didn't realize we were already expanding 24/32-bit division here already. Use the available IntegerDivision utilities. This uses loops, so produces significantly smaller code than the inline DAG expansion. This now requires width reductions of 64-bit divisions before introducing the expanded loops. This helps work around missing legalization in GlobalISel for division, which are the only remaining core instructions that didn't work at all. I think this is plausibly a better implementation than exists in the DAG, although turning it on by default misses out on the constant value optimizations and also needs benchmarking.
-
Craig Topper authored
-
Craig Topper authored
-
Alina Sbirlea authored
Summary: Potential fix for: https://bugs.llvm.org/show_bug.cgi?id=44889 and https://bugs.llvm.org/show_bug.cgi?id=44408 In the legacy pass manager, loop rotate need not compute MemorySSA when not being in the same loop pass manager with other loop passes. There isn't currently a way to differentiate between the two cases, so this attempts to limit the usage in LoopRotate to only update MemorySSA when the analysis is already available. The side-effect of this is that it will split the Loop pipeline. This issue does not apply to the new pass manager, where we have a flag specifying if all loop passes in that loop pass manager preserve MemorySSA. Reviewers: dmgreen, fedor.sergeev, nikic Subscribers: Prazek, hiraditya, george.burgess.iv, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D74574
-
Matt Arsenault authored
This is more or less directly ported from the AMDGPU custom lowering for FP_TO_FP16. I made a few minor fixups (using G_UNMERGE_VALUES instead of creating shift/trunc to extract the two halves, and zexting an inverted compare instead of select_cc). This also does not include the fast math expansion the DAG which converts to f32 and then to f16. I think that belongs in a pre-legalize combine instead.
-
Volkan Keles authored
Like COPY instructions explained in D70616, we don't check the constraints when combining G_UNMERGE_VALUES. Use the same logic used in D70616 to check if registers can be replaced, or a COPY instruction needs to be built. https://reviews.llvm.org/D70564
-
Brian Cain authored
Assembler now permits pairs like 'v0:1', which are encoded differently from the odd-first pairs like 'v1:0'. The compiler will require more work to leverage these new register pairs.
-
Aaron Puchert authored
We don't want to test for this warning, so we just fix it.
-
Aaron Puchert authored
Summary: Zero-parameter K&R definitions specify that the function has no parameters, but they are still not prototypes, so calling the function with the wrong number of parameters is just a warning, not an error. The C11 standard doesn't seem to directly define what a prototype is, but it can be inferred from 6.9.1p7: "If the declarator includes a parameter type list, the list also specifies the types of all the parameters; such a declarator also serves as a function prototype for later calls to the same function in the same translation unit." This refers to 6.7.6.3p5: "If, in the declaration “T D1”, D1 has the form D(parameter-type-list) or D(identifier-list_opt) [...]". Later in 6.11.7 it also refers only to the parameter-type-list variant as prototype: "The use of function definitions with separate parameter identifier and declaration lists (not prototype-format parameter type and identifier declarators) is an obsolescent feature." We already correctly treat an empty parameter list as non-prototype declaration, so we can just take that information. GCC also warns about this with -Wstrict-prototypes. This shouldn't affect C++, because there all FunctionType's are FunctionProtoTypes. I added a simple test for that. Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D66919
-
Simon Pilgrim authored
As noted on D74621 we currently have no test coverage
-
Matt Arsenault authored
-
Jonas Devlieghere authored
Rename LLDB_PLUGIN to LLDB_PLUGIN_DEFINE as Pavel suggested in D73067 to avoid name conflict.
-
Eric Fiselier authored
-
Matt Arsenault authored
-
Craig Topper authored
-
Matt Arsenault authored
-
Jenkins CI authored
-
Matt Arsenault authored
-
Eric Fiselier authored
This was caused by byte depending on traits. This patch moves the minimal amount of meta-programming into <cstddef> to break the cycle.
-
Alexandre Ganea authored
Also fix BitVector unittest failure when DLLVM_ENABLE_ASSERTIONS are OFF, introduced by d110c3a9.
-
Fangrui Song authored
AddGoldPlugin does more than adding `-plugin path/to/LLVMgold.so`. It works with lld and GNU ld, and adds other LTO options. So AddGoldPlugin is no longer a suitable name. Reviewed By: tejohnson Differential Revision: https://reviews.llvm.org/D74591
-
Evgeniy Brevnov authored
Reverting D73027 [DependenceAnalysis] Dependecies for loads marked with "ivnariant.load" should not be shared with general accesses(PR42151).
-
Eric Fiselier authored
-
Melanie Blower authored
This reverts commit 0a1123eb. Want to revert this because it's causing trouble for PowerPC I also fixed test fp-model.c which was looking for an incorrect error message
-
Alexandre Ganea authored
The goal of this patch is to maximize CPU utilization on multi-socket or high core count systems, so that parallel computations such as LLD/ThinLTO can use all hardware threads in the system. Before this patch, on Windows, a maximum of 64 hardware threads could be used at most, in some cases dispatched only on one CPU socket. == Background == Windows doesn't have a flat cpu_set_t like Linux. Instead, it projects hardware CPUs (or NUMA nodes) to applications through a concept of "processor groups". A "processor" is the smallest unit of execution on a CPU, that is, an hyper-thread if SMT is active; a core otherwise. There's a limit of 32-bit processors on older 32-bit versions of Windows, which later was raised to 64-processors with 64-bit versions of Windows. This limit comes from the affinity mask, which historically is represented by the sizeof(void*). Consequently, the concept of "processor groups" was introduced for dealing with systems with more than 64 hyper-threads. By default, the Windows OS assigns only one "processor group" to each starting application, in a round-robin manner. If the application wants to use more processors, it needs to programmatically enable it, by assigning threads to other "processor groups". This also means that affinity cannot cross "processor group" boundaries; one can only specify a "preferred" group on start-up, but the application is free to allocate more groups if it wants to. This creates a peculiar situation, where newer CPUs like the AMD EPYC 7702P (64-cores, 128-hyperthreads) are projected by the OS as two (2) "processor groups". This means that by default, an application can only use half of the cores. This situation could only get worse in the years to come, as dies with more cores will appear on the market. == The problem == The heavyweight_hardware_concurrency() API was introduced so that only *one hardware thread per core* was used. Once that API returns, that original intention is lost, only the number of threads is retained. Consider a situation, on Windows, where the system has 2 CPU sockets, 18 cores each, each core having 2 hyper-threads, for a total of 72 hyper-threads. Both heavyweight_hardware_concurrency() and hardware_concurrency() currently return 36, because on Windows they are simply wrappers over std::thread::hardware_concurrency() -- which can only return processors from the current "processor group". == The changes in this patch == To solve this situation, we capture (and retain) the initial intention until the point of usage, through a new ThreadPoolStrategy class. The number of threads to use is deferred as late as possible, until the moment where the std::threads are created (ThreadPool in the case of ThinLTO). When using hardware_concurrency(), setting ThreadCount to 0 now means to use all the possible hardware CPU (SMT) threads. Providing a ThreadCount above to the maximum number of threads will have no effect, the maximum will be used instead. The heavyweight_hardware_concurrency() is similar to hardware_concurrency(), except that only one thread per hardware *core* will be used. When LLVM_ENABLE_THREADS is OFF, the threading APIs will always return 1, to ensure any caller loops will be exercised at least once. Differential Revision: https://reviews.llvm.org/D71775
-
Alexandre Ganea authored
Use a ThreadPool instead of plain std::threads in clang-scan-deps. This is needed to further support https://reviews.llvm.org/D71775. Differential Revision: https://reviews.llvm.org/D74569
-
Alexandre Ganea authored
This patch adds DenseMapInfo<> support for BitVector and SmallBitVector. This is part of https://reviews.llvm.org/D71775, where a BitVector is used as a thread affinity mask.
-
Alex Richardson authored
Use the same appraoch as update_llc_test_checks.py to always write \n line endings. This should fix the Windows buildbots.
-
Louis Dionne authored
There are some unnecessary typenames in std/numerics/c.math/abs.pass.cpp; e.g. they're not in a dependent context. Patch by Bryce Adelstein Lelbach Differential Revision: https://reviews.llvm.org/D72106
-
Luís Marques authored
This reverts commit 1d40c415. This seemed to have caused build failures on ARM/AArch64.
-