Previously the code used getActiveBits() to determine the highest set
bit of each APInt first. However doing so requires the same amount of
memory accesses as simply comparing both numbers right away.
Removing all the active bit checks leads to simpler code and is faster
in my benchmark.
Differential Revision: http://reviews.llvm.org/D16620
llvm-svn: 260447
Summary:
This patch adds Windows support for a few of the llvm-config commands,
including cflags, ldflags, libs, and system-libs.
Currently llvm-config is untested, so this patch adds tests for the
commands that it fixes as well.
Reviewers: rnk
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D16762
llvm-svn: 260263
Most of the time we only hit the small case, so it is beneficial to pull
it out of the insert_imp() implementation. This improves compile time
at least for non-LTO builds.
Differential Revision: http://reviews.llvm.org/D16619
llvm-svn: 258908
at least as big as the mach header to be identified as a Mach-O file and
make sure smaller files are not identified as a Mach-O files but as
unknown files. Also fix identify_magic() so it looks at all 4 bytes of
the filetype field when determining the type of the Mach-O file.
Then fix the macho-invalid-header test case to check that it is an
unknown file and make sure it does not get the error for
object_error::parse_failed. And also update the unit tests.
llvm-svn: 258883
Summary:
This patch is provided in preparation for removing autoconf on 1/26. The proposal to remove autoconf on 1/26 was discussed on the llvm-dev thread here: http://lists.llvm.org/pipermail/llvm-dev/2016-January/093875.html
"I felt a great disturbance in the [build system], as if millions of [makefiles] suddenly cried out in terror and were suddenly silenced. I fear something [amazing] has happened."
- Obi Wan Kenobi
Reviewers: chandlerc, grosbach, bob.wilson, tstellarAMD, echristo, whitequark
Subscribers: chfast, simoncook, emaste, jholewinski, tberghammer, jfb, danalbert, srhines, arsenm, dschuff, jyknight, dsanders, joker.eph, llvm-commits
Differential Revision: http://reviews.llvm.org/D16471
llvm-svn: 258861
This patch was originally committed as r257885, but was reverted due to windows
failures. The cause of these failures has been fixed under r258677, hence
re-committing the original patch.
llvm-svn: 258683
Changes in X86.td:
I set features of Intel processors in incremental form: IVB = SNB + X HSW = IVB + X ..
I added Skylake client processor and defined it's features
FeatureADX was missing on KNL
Added some new features to appropriate processors SMAP, IFMA, PREFETCHWT1, VMFUNC and others
Differential Revision: http://reviews.llvm.org/D16357
llvm-svn: 258659
The feature flag is for VPERMB,VPERMI2B,VPERMT2B and VPMULTISHIFTQB instructions.
More about the instruction can be found in:
hattps://software.intel.com/sites/default/files/managed/07/b7/319433-023.pdf
Differential Revision: http://reviews.llvm.org/D16190
llvm-svn: 258012
# The first commit's message is:
Revert "[ARM] Add DSP build attribute and extension targeting"
This reverts commit b11cc50c0b4a7c8cdb628abc50b7dc226ff583dc.
# This is the 2nd commit message:
Revert "[ARM] Add new system registers to ARMv8-M Baseline/Mainline"
This reverts commit 837d08454e3e5beb8581951ac26b22fa07df3cd5.
llvm-svn: 257916
This means that the DEBUG_TYPE cannot take a comma anymore. All existing passes
conform to this rule.
Differential Revision: http://reviews.llvm.org/D15645
llvm-svn: 257466
Apparently the preferred version is the incredibly complicated
VerifyVersionInfoW function.
Rename the function to avoid potential future name clashes.
llvm-svn: 257415
This reverts commit r254363.
load64BitDebugHelp() has the side effect of loading dbghelp and setting
globals. It should be called in no-asserts builds as well as debug
builds.
llvm_unreachable is also not appropriate here, since we actually want to
return if dbghelp couldn't be loaded in a non-asserts build.
llvm-svn: 257384
This removes ifdefs and fixes the build for users of the Win8.0 SDK,
which I happen to be. Upgrading is not hard, but executing the same code
everywhere seems better.
llvm-svn: 257379
The new leader is known anyway so we can return it for some micro
optimization in code where it is easy to pass along the result to the
next join().
llvm-svn: 257130
Change Triple::get32BitArchVariant to return arm/armeb as the 32bit
variant of aarch64/aarch64_be and do the same change for the oppoiste
direction in Triple::get64BitArchVariant.
Differential revision: http://reviews.llvm.org/D15529
llvm-svn: 257048
confused with what version of mingw is actually installed on the buildbot, and
for now I will just assume this is an unknown version which does not ship with
VersionHelpers.h.
llvm-svn: 256902
This patch is similar to the Python issue#11395. We need to cap the output
size to 32767 on Windows to work around the size limit of WriteConsole().
Reference: https://bugs.python.org/issue11395
Writing a test for this bug turns out to be harder than I thought. I am
still working on it (see phabricator review D15705).
Differential Revision: http://reviews.llvm.org/D15553
llvm-svn: 256892
Summary:
Hi Rafael,
Would you be able to review this patch, please?
(Clang part of the patch is D15832).
When clang runs an external tool, e.g. a linker, it may create a command line that exceeds the length limit.
Clang uses the llvm::sys::argumentsFitWithinSystemLimits function to check if command line length fits the OS
limitation. There are two problems in this function that may cause exceeding of the limit:
1. It ignores the length of the program path in its calculations. On the other hand, clang adds the program
path to the command line when it runs the program.
2. It assumes no space character is inserted after the last argument, which is not true for Windows. The flattenArgs function adds the trailing space for *each* argument. The result of this is that the terminating NULL character is not counted and may be placed beyond the length limit if the command line is exactly 32768 characters long. The WinAPI's CreateProcess does not find the NULL character and fails.
Reviewers: rafael, ygao, probinson
Subscribers: asl, llvm-commits
Differential Revision: http://reviews.llvm.org/D15831
llvm-svn: 256866
InitMCObjectFileInfo was trying to override the triple in awkward ways.
For example, a triple specifying COFF but not Windows was forced as ELF.
This makes it easy for internal invariants to get violated, such as
those which triggered PR25912.
This fixes PR25912.
llvm-svn: 256226
Type specific declarations have been moved to Type.h and error handling
routines have been moved to ErrorHandling.h. Both are included in Core.h
so nothing should change for projects directly including the headers,
but transitive dependencies may be affected.
llvm-svn: 255965
This creates the initial infrastructure for writing ELF output files. It
doesn't yet have any implementation for encoding instructions.
Differential Revision: http://reviews.llvm.org/D15555
llvm-svn: 255869
It looks like the code this patch deletes is based on a misunderstanding of
what guarantees writev provides. In particular, writev with 1 iovec is
not "more atomic" than a write.
Testing on OS X shows that both write and writev from multiple processes
can be intermixed.
llvm-svn: 255837
Jacques Pienaar