| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
subrange
The current pattern for extract bits in range is typically:
Mask.lshr(BitOffset).trunc(SubSizeInBits);
Which can be particularly slow for large APInts (MaskSizeInBits > 64) as they require the allocation of memory for the temporary variable.
This is another of the compile time issues identified in PR32037 (see also D30265).
This patch adds the APInt::extractBits() helper method which avoids the temporary memory allocation.
Differential Revision: https://reviews.llvm.org/D30336
llvm-svn: 296147
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The current pattern for extract bits in range is typically:
Mask.lshr(BitOffset).trunc(SubSizeInBits);
Which can be particularly slow for large APInts (MaskSizeInBits > 64) as they require the allocation of memory for the temporary variable.
This is another of the compile time issues identified in PR32037 (see also D30265).
This patch adds the APInt::extractBits() helper method which avoids the temporary memory allocation.
Differential Revision: https://reviews.llvm.org/D30336
llvm-svn: 296141
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The current pattern for setting bits in range is typically:
Mask |= APInt::getBitsSet(MaskSizeInBits, LoPos, HiPos);
Which can be particularly slow for large APInts (MaskSizeInBits > 64) as they require the allocation memory for the temporary variable.
This is one of the key compile time issues identified in PR32037.
This patch adds the APInt::setBits() helper method which avoids the temporary memory allocation completely, this first implementation uses setBit() internally instead but already significantly reduces the regression in PR32037 (~10% drop). Additional optimization may be possible.
I investigated whether there is need for APInt::clearBits() and APInt::flipBits() equivalents but haven't seen these patterns to be particularly common, but reusing the code would be trivial.
Differential Revision: https://reviews.llvm.org/D30265
llvm-svn: 296102
|
| |
|
|
| |
llvm-svn: 295989
|
| |
|
|
|
|
|
|
| |
The problem appears to be that these flags can only be used
when mapping a file for read-only, not for readwrite. So
we do that here.
llvm-svn: 295880
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The function for distinguishing local and remote files added in r295768
unconditionally uses linux/magic.h header to provide necessary
filesystem magic numbers. However, in kernel headers predating 2.6.18
the magic numbers are spread throughout multiple include files.
Furthermore, LLVM did not require kernel headers being installed so far.
To increase the portability across different versions of Linux kernel
and different Linux systems, add CMake header checks for linux/magic.h
and -- if it is missing -- the linux/nfs_fs.h and linux/smb.h headers
which contained the numbers previously.
Furthermore, since the numbers are static and the feature does not seem
critical enough to make LLVM require kernel headers at all, add fallback
constants for the case when none of the necessary headers is available.
Differential Revision: https://reviews.llvm.org/D30261
llvm-svn: 295854
|
| |
|
|
|
|
|
|
|
| |
Since I'm only seeing failures on OSX, and it's saying
permission denied, I'm suspecting this is due to the addition
of the MAP_RESILIENT_CODESIGN and/or MAP_RESILIENT_MEDIA flags.
Speculatively trying to remove those to get the bots working.
llvm-svn: 295770
|
| |
|
|
| |
llvm-svn: 295769
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D30010
llvm-svn: 295768
|
| |
|
|
| |
llvm-svn: 295759
|
| |
|
|
|
|
| |
There are still over 3400 files remaining with this property set, but there are tens of thousands more with the property not set. Until we decide what to do on a global scale, this at least unblocks me temporarily.
llvm-svn: 295756
|
| |
|
|
|
|
| |
Reviewed by Vedant Kumar (D30178)
llvm-svn: 295737
|
| |
|
|
| |
llvm-svn: 295595
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
We have support for bisection, and bugpoint can reduce testcases
often to a single pass. But that doesn't help reduce it to a single
transform by a single pass. Which debug counting lets us do.
Debug counting lets you instrument a pass so that it only executes a
certain thing (rwhatever you want) after skipping it a certain time of
times, and then only does a certain number of executions before saying
"skip" again.
To make it concrete, for predicateinfo, if i instrument use renaming,
i can make it so it skips renaming the first N uses, renames the next
N, and then skips the rest.
This lets you narrow down a miscompilation to, often, a single
transformation, and then also debug it (by using the same command line
parameters).
Reviewers: chandlerc, davide, mehdi_amini
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D29998
llvm-svn: 295593
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This set of patches adds support for Cavium ThunderX ARM64 processors:
* ThunderX
* ThunderX T81
* ThunderX T83
* ThunderX T88
Patch by Stefan Teleman
Differential Revision: https://reviews.llvm.org/D28891
llvm-svn: 295475
|
| |
|
|
|
|
|
|
|
|
|
| |
TimerGroup was showing up on a leak in valigrind, and
used some pretty complex code to implement a singleton.
This patch replaces the implementation with a vastly simpler
one.
Differential Revision: https://reviews.llvm.org/D28367
llvm-svn: 295370
|
| |
|
|
|
|
| |
other minor fixes (NFC).
llvm-svn: 295243
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D29918
llvm-svn: 295089
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
LLVM defines `PTHREAD_LIB` which is used by AddLLVM.cmake and various projects
to correctly link the threading library when needed. Unfortunately
`PTHREAD_LIB` is defined by LLVM's `config-ix.cmake` file which isn't installed
and therefore can't be used when configuring out-of-tree builds. This causes
such builds to fail since `pthread` isn't being correctly linked.
This patch attempts to fix that problem by renaming and exporting
`LLVM_PTHREAD_LIB` as part of`LLVMConfig.cmake`. I renamed `PTHREAD_LIB`
because It seemed likely to cause collisions with downstream users of
`LLVMConfig.cmake`.
llvm-svn: 294690
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Gcc supports target armv7ve which is armv7-a with virtualization
extensions. This change adds support for this in llvm for gcc
compatibility.
Also remove redundant FeatureHWDiv, FeatureHWDivARM for a few models as
this is specified automatically by FeatureVirtualization.
Patch by Manoj Gupta.
Differential Revision: https://reviews.llvm.org/D29472
llvm-svn: 294661
|
| |
|
|
|
|
| |
We only implemented it for one of the 3 HLE instructions and that instruction is also under the RTM flag. Clang only implements the RTM flag from its command line.
llvm-svn: 294562
|
| |
|
|
|
|
|
|
| |
any instructions and not tested.
If we implement intrinsics for their instructions in the future, the feature flags can be added back with proper testing.
llvm-svn: 294561
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch does the following.
1. Adds an Intrinsic int_x86_clzero which works with __builtin_ia32_clzero
2. Identifies clzero feature using cpuid info. (Function:8000_0008, Checks if EBX[0]=1)
3. Adds the clzero feature under znver1 architecture.
4. The custom inserter is added in Lowering.
5. A testcase is added to check the intrinsic.
6. The clzero instruction is added to assembler test.
Patch by Ganesh Gopalasubramanian with a couple formatting tweaks, a disassembler test, and using update_llc_test.py from me.
Differential revision: https://reviews.llvm.org/D29385
llvm-svn: 294558
|
| |
|
|
|
|
|
|
| |
instruction with no plans to release products with it.
Intel's documentation for the deprecation https://software.intel.com/en-us/blogs/2016/09/12/deprecate-pcommit-instruction
llvm-svn: 294405
|
| |
|
|
|
|
| |
MSVC does not think that `char []` can be constexpr. Switch to regular const.
llvm-svn: 294327
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The formatter has three knobs:
- the user can choose which time unit to use for formatting (default: whatever is the unit of the input)
- he can choose whether the unit gets displayed (default: yes)
- he can affect the way the number itself is formatted via standard number formatting options (default:default)
Reviewers: zturner, inglorion
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D29481
llvm-svn: 294326
|
| |
|
|
|
| |
Review: https://reviews.llvm.org/D27749
llvm-svn: 294295
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Make this interface reusable similarly to std::call_once and std::once_flag interface.
This makes porting LLDB to NetBSD easier as there was in the original approach a portable way to specify a non-static once_flag. With this change translating std::once_flag to llvm::once_flag is mechanical.
Sponsored by <The NetBSD Foundation>
Reviewers: mehdi_amini, labath, joerg
Reviewed By: mehdi_amini
Subscribers: emaste, clayborg
Differential Revision: https://reviews.llvm.org/D29566
llvm-svn: 294143
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: As per title. I ran into that limitation of the API doing some other work, so I though that'd be a nice addition.
Reviewers: jroelofs, compnerd, majnemer
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D29503
llvm-svn: 294063
|
| |
|
|
|
|
|
|
|
| |
Committing after fixing suggested changes and tested release/debug builds on
x86_64-linux and arm/aarch64 builds.
Differential revision: https://reviews.llvm.org/D29042
llvm-svn: 293850
|
| |
|
|
|
|
|
| |
This annoyed me a few times but was lazy so I haven't fixed it
until today, when the output of my debugger was too confusing.
llvm-svn: 293691
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We had various variants of defining dump() functions in LLVM. Normalize
them (this should just consistently implement the things discussed in
http://lists.llvm.org/pipermail/cfe-dev/2014-January/034323.html
For reference:
- Public headers should just declare the dump() method but not use
LLVM_DUMP_METHOD or #if !defined(NDEBUG) || defined(LLVM_ENABLE_DUMP)
- The definition of a dump method should look like this:
#if !defined(NDEBUG) || defined(LLVM_ENABLE_DUMP)
LLVM_DUMP_METHOD void MyClass::dump() {
// print stuff to dbgs()...
}
#endif
llvm-svn: 293359
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: This is an attempt to reduce the verbose manual dispatching code in APFloat. This doesn't handle multiple dispatch on single discriminator (e.g. APFloat::add(const APFloat&)), nor handles multiple dispatch on multiple discriminators (e.g. APFloat::convert()).
Reviewers: hfinkel, echristo, jlebar
Subscribers: mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D29161
llvm-svn: 293255
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: Fix comments in response to jlebar's comments in D27872.
Reviewers: jlebar
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D29109
llvm-svn: 293116
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Use the O_CLOEXEC flag only when it is available. Some old systems (e.g.
SLES10) do not support this flag. POSIX explicitly guarantees that this
flag can be checked for using #if, so there is no need for a CMake
check.
In case O_CLOEXEC is not supported, fall back to fcntl(FD_CLOEXEC)
instead.
Reviewers: rnk, rafael, mgorny
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D28894
llvm-svn: 292912
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This adds a cross-platform way of setting the current working directory
analogous to the existing current_path() function used for retrieving
it. The function will be used in lldb.
Reviewers: rafael, silvas, zturner
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D29035
llvm-svn: 292907
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
There's a comment in XorSlowCase that says "0^0==1" which isn't true. 0 xored with 0 is still 0. So I don't think we need to clear any unused bits here.
Now there is no difference between XorSlowCase and AndSlowCase/OrSlowCase other than the operation being performed
Reviewers: majnemer, MatzeB, chandlerc, bkramer
Reviewed By: MatzeB
Subscribers: chfast, llvm-commits
Differential Revision: https://reviews.llvm.org/D28986
llvm-svn: 292873
|
| |
|
|
|
|
|
|
|
|
| |
Reviewers: echristo, hfinkel, kbarton, iteratee
Subscribers: mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D28382
llvm-svn: 292860
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(IEEEdouble, IEEEdouble)
Summary:
This patch changes the layout of DoubleAPFloat, and adjust all
operations to do either:
1) (IEEEdouble, IEEEdouble) -> (uint64_t, uint64_t) -> PPCDoubleDoubleImpl,
then run the old algorithm.
2) Do the right thing directly.
1) includes multiply, divide, remainder, mod, fusedMultiplyAdd, roundToIntegral,
convertFromString, next, convertToInteger, convertFromAPInt,
convertFromSignExtendedInteger, convertFromZeroExtendedInteger,
convertToHexString, toString, getExactInverse.
2) includes makeZero, makeLargest, makeSmallest, makeSmallestNormalized,
compare, bitwiseIsEqual, bitcastToAPInt, isDenormal, isSmallest,
isLargest, isInteger, ilogb, scalbn, frexp, hash_value, Profile.
I could split this into two patches, e.g. use
1) for all operatoins first, then incrementally change some of them to
2). I didn't do that, because 1) involves code that converts data between
PPCDoubleDoubleImpl and (IEEEdouble, IEEEdouble) back and forth, and may
pessimize the compiler. Instead, I find easy functions and use
approach 2) for them directly.
Next step is to implement move multiply and divide from 1) to 2). I don't
have plans for other functions in 1).
Differential Revision: https://reviews.llvm.org/D27872
llvm-svn: 292839
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This makes the file descriptors on unix platform non-inheritable (O_CLOEXEC).
There is no change in behavior on windows, as the handles were already
non-inheritable there.
Reviewers: rnk, rafael
Subscribers: llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D28854
llvm-svn: 292401
|
| |
|
|
|
|
|
|
|
|
|
| |
Enable an ELFObjectFile to read the its arm build attributes to
produce a target triple with a specific ARM architecture.
llvm-objdump now uses this functionality to automatically produce
a more accurate target.
Differential Revision: https://reviews.llvm.org/D28769
llvm-svn: 292366
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D26701
llvm-svn: 292252
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
instead of custom status"
No any changes, will follow up with D28807 commit containing APLi change for clang
to fix build issues happened.
Original commit message:
[Support/Compression] - Change zlib API to return Error instead of custom status.
Previously API returned custom enum values.
Patch changes it to return Error with string description.
That should help users to report errors in universal way.
Differential revision: https://reviews.llvm.org/D28684
llvm-svn: 292226
|
| |
|
|
|
|
|
|
|
| |
instead of custom status."
It broked clang:
http://lab.llvm.org:8080/green//job/clang-stage1-cmake-RA-incremental_build/34218/consoleFull#46141505449ba4694-19c4-4d7e-bec5-911270d8a58c
llvm-svn: 292217
|
| |
|
|
|
|
|
|
|
|
|
|
| |
status.
Previously API returned custom enum values.
Patch changes it to return Error with string description.
That should help users to report errors in universal way.
Differential revision: https://reviews.llvm.org/D28684
llvm-svn: 292214
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Revert [ARM] Fix ubig32_t read in ARMAttributeParser
Now using support functions to read data instead of trying to
perform casts.
===========================================================
Revert [ARM] Enable objdump to construct triple for ARM
Now that The ARMAttributeParser has been moved into the library,
it has been modified so that it can parse the attributes without
printing them and stores them in a map. ELFObjectFile now queries
the attributes to fill out the architecture details of a provided
triple for 'arm' and 'thumb' targets. llvm-objdump uses this new
functionality.
Subscribers: llvm-commits, samparker, aemerson, mgorny
Differential Revision: https://reviews.llvm.org/D28683
llvm-svn: 291911
|
| |
|
|
|
|
|
|
|
| |
Now using support functions to read data instead of trying to
perform casts.
Differential Revision: https://reviews.llvm.org/D28669
llvm-svn: 291903
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Now that The ARMAttributeParser has been moved into the library,
it has been modified so that it can parse the attributes without
printing them and stores them in a map. ELFObjectFile now queries
the attributes to fill out the architecture details of a provided
triple for 'arm' and 'thumb' targets. llvm-objdump uses this new
functionality.
Differential Revision: https://reviews.llvm.org/D28281
llvm-svn: 291898
|
| |
|
|
|
|
|
|
|
| |
Moved ARMAttributeParser out of llvm-readobj and into the support
library.
Differential Revision: https://reviews.llvm.org/D28227
llvm-svn: 291896
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch enables the following
1. AMD family 17h architecture using "znver1" tune flag (-march, -mcpu).
2. ISAs that are enabled for "znver1" architecture.
3. Checks ADX isa from cpuid to identify "znver1" flag when -march=native is used.
4. ISAs FMA4, XOP are disabled as they are dropped from amdfam17.
5. For the time being, it uses the btver2 scheduler model.
6. Test file is updated to check this flag.
This item is linked to clang review item https://reviews.llvm.org/D28018
Patch by Ganesh Gopalasubramanian
Reviewers: RKSimon, craig.topper
Subscribers: vprasad, RKSimon, ashutosh.nema, llvm-commits
Differential Revision: https://reviews.llvm.org/D28017
llvm-svn: 291543
|