Accomplished by moving the body of StringRef::edit_distance into
a separate function that accepts two ArrayRefs, and making
StringRef::edit_distance a wrapper around the new function.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@150621 91177308-0d34-0410-b5e6-96231b3b80d8
the process. Some of these are still a bit gross.
Still, this cuts 80 some lines out of this ridiculous file. ;]
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@150331 91177308-0d34-0410-b5e6-96231b3b80d8
Unify default construction of error_code uses on this idiom so that users don't
feel compelled to make static globals for naming convenience. (unfortunately I
couldn't make the original ctor private as some APIs don't return their result,
instead using an out parameter (that makes sense to default construct) - which
is a bit of a pity. I did, however, find/fix some cases of unnecessary default
construction of error_code before I hit the unfixable cases)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@150197 91177308-0d34-0410-b5e6-96231b3b80d8
If someone would prefer a clear name for the 'success' error_value we could
come up with one - potentially just a 'named constructor' style
'error_value::success()' to make this expression more self-documenting. If
I see this come up in other cases I'll certainly consider it.
One step along the way to resolving PR11944.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@150120 91177308-0d34-0410-b5e6-96231b3b80d8
This CL delays reading of function bodies from initial parse until
materialization, allowing overlap of compilation with bitcode download.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@149918 91177308-0d34-0410-b5e6-96231b3b80d8
some architectures. These are useful for interacting with multiarch or
bi-arch GCC (or GCC-based) toolchains.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@149895 91177308-0d34-0410-b5e6-96231b3b80d8
This new function provides a way to get the Mac OS X version number from
either generic "darwin" triples of macosx triples.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@149438 91177308-0d34-0410-b5e6-96231b3b80d8
(This time I believe I've checked all the -Wreturn-type warnings from GCC & added the couple of llvm_unreachables necessary to silence them. If I've missed any, I'll happily fix them as soon as I know about them)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@148262 91177308-0d34-0410-b5e6-96231b3b80d8
or Clang is using this, and it would be hard to use it correctly given
the thread hostility of the function. Also, it never checked the return
which is rather dangerous with chdir. If someone was in fact using this,
please let me know, as well as what the usecase actually is so that
I can add it back and make it more correct and secure to use. (That
said, it's never going to be "safe" per-se, but we could at least
document the risks...)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@148211 91177308-0d34-0410-b5e6-96231b3b80d8
of several newly un-defaulted switches. This also helps optimizers
(including LLVM's) recognize that every case is covered, and we should
assume as much.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147861 91177308-0d34-0410-b5e6-96231b3b80d8
Get back getHostTriple.
For JIT compilation, use the host triple instead of the default
target: this fixes some JIT testcases that used to fail when the
compiler has been configured as a cross compiler.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147542 91177308-0d34-0410-b5e6-96231b3b80d8
- -25% memory usage of the main table on x86_64 (was wasted in struct padding).
- no significant performance change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147294 91177308-0d34-0410-b5e6-96231b3b80d8
Diagnostics are now emitted via the SourceMgr and we use MemoryBuffer
for buffer management. Switched the code to make use of the trailing
'0' that MemoryBuffer guarantees where it makes sense.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147063 91177308-0d34-0410-b5e6-96231b3b80d8
Pulling the template implementation into the header to guarantee
that it's visible to all possible instantiations.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146973 91177308-0d34-0410-b5e6-96231b3b80d8
memory fences) in statistics registration, which works the same way that
ManagedStatic registration does.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145869 91177308-0d34-0410-b5e6-96231b3b80d8
clang/lib/Driver/Driver.cpp: Don't pass through negative exit status, or parent would be confused.
llvm::sys::Program::Wait(): Suppose 0x8000XXXX and 0xC000XXXX as abnormal exit code and pass it as negative value.
Win32 Exception Handler: Exit with ExceptionCode on an unhandle exception.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145389 91177308-0d34-0410-b5e6-96231b3b80d8
Now that it needs to be exported in a public header (Valgrind.h)
it should be prefixed to avoid collision with other projects.
Add it to llvm-config.h as well.
This'll require regenerating the configure script after this
commit, but I don't have the required autoconf version.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145214 91177308-0d34-0410-b5e6-96231b3b80d8
was returning incorrect values in rare cases, and incorrectly marking
exact conversions as inexact in some more common cases. Fixes PR11406, and a
missed optimization in test/CodeGen/X86/fp-stack-O0.ll.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145141 91177308-0d34-0410-b5e6-96231b3b80d8
This was put in because in a certain version of DragonFlyBSD stat(2) lied about the
size of some files. This was fixed a long time ago so we can remove the workaround.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145059 91177308-0d34-0410-b5e6-96231b3b80d8
These annotations are disabled entirely when either ENABLE_THREADS is off, or
building a release build. When enabled, they add calls to functions with no
statements to ManagedStatic's getters.
Use these annotations to inform tsan that the race used inside ManagedStatic
initialization is actually benign. Thanks to Kostya Serebryany for helping
write this patch!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144567 91177308-0d34-0410-b5e6-96231b3b80d8
the X86 asmparser to produce ranges in the one case that was annoying me, for example:
test.s:10:15: error: invalid operand for instruction
movl 0(%rax), 0(%edx)
^~~~~~~
It should be straight-forward to enhance filecheck, tblgen, and/or the .ll parser to use
ranges where appropriate if someone is interested.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142106 91177308-0d34-0410-b5e6-96231b3b80d8
Based on Horspool's simplified version of Boyer-Moore. We use a constant-sized table of
uint8_ts to keep cache thrashing low, needles bigger than 255 bytes are uncommon anyways.
The worst case is still O(n*m) but we do a lot better on the average case now.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142061 91177308-0d34-0410-b5e6-96231b3b80d8
It extremely breaks builds when optimization is enabled. Twine should not hold temporary objects.
By the way, I might feel sad if I saw "i786-" "i1586-" or "iF86-".
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142055 91177308-0d34-0410-b5e6-96231b3b80d8
from config.h, it discovers the triple based on the execution environment.
Patch by Aaron Ballman <aaron@aaronballman.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142046 91177308-0d34-0410-b5e6-96231b3b80d8
compiled on mips32r1 processors because it uses synci and rdhwr instructions
which are supported only on mips32r2, so I replaced this function with the
call to function cacheflush which works for both mips32r1 and mips32r2.
Patch by Sasa Stankovic
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@141564 91177308-0d34-0410-b5e6-96231b3b80d8
assert(!"error message");
To:
assert(0 && "error message");
which is more consistant across the code base.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@140234 91177308-0d34-0410-b5e6-96231b3b80d8
This was only needed to locate llvm-gcc's installation directory when clang
falls back to run llvm-gcc for i386 kexts. As of clang svn r140187, we're
now just searching paths with several different Darwin versions on either
side of the current version, so this is no longer needed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@140188 91177308-0d34-0410-b5e6-96231b3b80d8
gold plugin is built with Large File Support (sizeof(off_t) == 64 on i686)
and the rest of LLVM is built w/o Large File Support
(sizeof(off_t) == 32 on i686) which corrupts the stack.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@139873 91177308-0d34-0410-b5e6-96231b3b80d8
will ignore the erasedOnReboot option, and properly escape the
backslash in "C:\TEMP". Thanks to Aaron and Francois.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@139755 91177308-0d34-0410-b5e6-96231b3b80d8
- Add TSFlags for the instruction formats. The idea here is to use
as much encoding as possible from getBinaryCodeForInstr, and having
TSFLags formats for that would make it easier to encode most part
of the instructions (since Mips encodings are pretty straightforward)
- Improve the mips mechanism for compilation callback
- Add Mips specific code for invalidating the instruction cache
- Next patch will address wrong tablegen encoding
Commit msg added by my own but the patch is from Sasa Stankovic.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@139688 91177308-0d34-0410-b5e6-96231b3b80d8
It is an endian-aware helper that can read data from a StringRef. It will
come in handy for DWARF parsing. This class is inspired by LLDB's
DataExtractor, but is stripped down to the bare minimum needed for DWARF.
Comes with unit tests!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@139626 91177308-0d34-0410-b5e6-96231b3b80d8
Before we just left the remaining bytes uninitialized. This is another step in making llvm valgrind-clean again.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@138705 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds support of NativeClient (*-*-nacl) OS support to LLVM.
It's already supported in autoconf/config.sub.
The motivation for this change is to start upstreaming PNaCl work. The
whole set of patches include llvm backends (i686, x86_64, ARM),
llvm-gcc (probably, would not be upstreamed because it's deprecated)
and clang (the work has been just started, the amount of changes is
going to be low and the most of the work is expected to be done close
to the mainline).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@138005 91177308-0d34-0410-b5e6-96231b3b80d8
When this variable is set, "uname -r" will return its value instead of the
real OS version. Make this affect LLVM's triple for consistency.
<rdar://problem/9919167>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@137111 91177308-0d34-0410-b5e6-96231b3b80d8
screwy things by setting PWD != getcwd(). For example, some developers I know
will use this to control the value in gcc's DW_AT_comp_dir value in debug
output. With this patch, that trick will now work on clang too.
The only other effect of this change is that the static analysis will now
respect $PWD when reporting the directory of the files in its HTML output. I
think that's fine.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@136459 91177308-0d34-0410-b5e6-96231b3b80d8
If true and 'model' parameter is not an absolute path, a temp directory will be prepended.
Make it true by default to match current behaviour.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@136310 91177308-0d34-0410-b5e6-96231b3b80d8
The header file was already properly located. The previous need for it
in Support had to do with the version string printing which was fixed in
r135757.
Also update build dependencies where libraries that needed the
functionality of the Target library (in the form of the TargetRegistry)
were picking it up via Support. This is pretty pervasive, essentially
every TargetInfo library (ARMInfo, etc) uses TargetRegistry, making it
depend on Target. All of these were previously just sneaking by.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@135760 91177308-0d34-0410-b5e6-96231b3b80d8
the Support library. Now its part of the TargetRegistry, and the three
commands that care about this explicitly register this extra bit of
version information.
The set of commands which care was computed by intersecting those which
use the Support library's version string printing and those that
initialize all the registered targets in a way that produces
a meaningful list. The only odd ball out is that 'clang -cc1as -version'
no longer prints the registered targets. I don't think anyone is really
interested in that (especially as the fact that llvm-mc does so is under
a FIXME), but if someone really does want this back I'll happily apply
the same patch there.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@135757 91177308-0d34-0410-b5e6-96231b3b80d8
function on the TargetRegistry. Also clean it up and use the modern LLVM
utility libraries available instead of rolling a few things manually.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@135756 91177308-0d34-0410-b5e6-96231b3b80d8
register extra version information to be printed. This is designed to
allow those tools which link in various targets to also print those
registered targets under --version.
Currently this printing logic is embedded into the Support library
directly; a huge layering violation. This is the first step to hoisting
it out into the tools without adding lots of duplicated code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@135755 91177308-0d34-0410-b5e6-96231b3b80d8
FIXME: There is an inconsistency. llvm::Triple does not understand "ppc32" and PowerPC/TargetInfo holds "ppc32".
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@135745 91177308-0d34-0410-b5e6-96231b3b80d8
errors like the one corrected by r135261. Migrate all LLVM callers of the old
constructor to the new one.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@135431 91177308-0d34-0410-b5e6-96231b3b80d8
desired overload.
This is a bit of a hackish workaround to fix the compile after r135259.
Let me know if there is a better approach.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@135261 91177308-0d34-0410-b5e6-96231b3b80d8
According to Intel Application Note 485, this value is used for
"Intel Core i7 and Intel Xeon processor". Just include it with the other
"corei7-avx" entries.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@134750 91177308-0d34-0410-b5e6-96231b3b80d8
toString() now takes an optional bool argument that,
depending on the radix, adds the appropriate prefix
to the integer's string representation that makes it into a
meaningful C literal, e.g.:
hexademical: '-f' becomes '-0xf'
octal: '77' becomes '077'
binary: '110' becomes '0b110'
Patch by nobled@dreamwidth.org!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@133032 91177308-0d34-0410-b5e6-96231b3b80d8
Patch by: Jakub Staszak!
Introduces BranchProbability. Changes unsigned to uint32_t all over and
uint64_t only when overflow is expected.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132867 91177308-0d34-0410-b5e6-96231b3b80d8
This is important for the correct lowering of unwind instructions
(which doesn't matter at all) and llvm.eh.resume calls (which does).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132291 91177308-0d34-0410-b5e6-96231b3b80d8
This change allows bugpoint to pinpoint the "opt" pass and bitcode
segment responsible for a crash caused by miscompilation. At least it
works well for me now, without having to create any custom execution
wrappers.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@131186 91177308-0d34-0410-b5e6-96231b3b80d8
comments claimed it did this, but the LHS value was actually an unused variable.
The new system considers only the '-foo' part when comparing it for typos
against flags that have values, but still look at the whole string for flags
that don't. That way, we'll still correct '-inst=combine' to '-instcombine'.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@130685 91177308-0d34-0410-b5e6-96231b3b80d8
used by Clang. To help Clang integration, the PTX target has been split
into two targets: ptx32 and ptx64, depending on the desired pointer size.
- Add GCCBuiltin class to all intrinsics
- Split PTX target into ptx32 and ptx64
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@129851 91177308-0d34-0410-b5e6-96231b3b80d8
developers can see if their driver changed any cl::Option's. The
current implementation isn't perfect but handles most kinds of
options. This is nice to have when decomposing the stages of
compilation and moving between different drivers. It's also a good
sanity check when comparing results produced by different command line
invocations that are expected to produce the comparable results.
Note: This is not an attempt to prolong the life of cl::Option. On the
contrary, it's a placeholder for a feature that must exist when
cl::Option is replaced by a more appropriate framework. A new
framework needs: a central option registry, dynamic name lookup,
non-global containers of option values (e.g. per-module,
per-function), *and* the ability to print options values and their defaults at
any point during compilation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@128910 91177308-0d34-0410-b5e6-96231b3b80d8
- Adds support for sniffing PE/COFF files on win32 (.exe and .dll)
which are COFF files that have an MS-DOS compatibility stub on
the front of them.
- Fixes a bug in the COFFObjectFile's support for the Microsoft COFF
extension for long symbol names, wherein it was attempting to parse
the leading '/' in an extended symbol name reference as part of the
integer offset.
- Fixes bugs in COFFObjectFile and ELFObjectFile wherein section
and symbol iterators were being returned with uninitialized bytes;
the type DataRefImpl is a union between 2 32-bit words (d.a and d.b)
and a single intptr_t word (p). Only p was being initialized, so in
32-bit builds the result would be iterators with random upper 32-bit
words in their DataRefImpls. This caused random failures when
seeking around in object files.
Patch by Graydon Hoare!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@128799 91177308-0d34-0410-b5e6-96231b3b80d8
StringMap was not properly updating NumTombstones after a clear or rehash.
This was not fatal until now because the table was growing faster than
NumTombstones could, but with the previous change of preventing infinite
growth of the table the invariant (NumItems + NumTombstones <= NumBuckets)
stopped being observed, causing infinite loops in certain situations.
Patch by José Fonseca!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@128567 91177308-0d34-0410-b5e6-96231b3b80d8
Some platforms may treat denormals as zero, on other platforms multiplication
with a subnormal is slower than dividing by a normal.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@128555 91177308-0d34-0410-b5e6-96231b3b80d8
The idea is, that if an ieee 754 float is divided by a power of two, we can
turn the division into a cheaper multiplication. This function sees if we can
get an exact multiplicative inverse for a divisor and returns it if possible.
This is the hard part of PR9587.
I tested many inputs against llvm-gcc's frotend implementation of this
optimization and didn't find any difference. However, floating point is the
land of weird edge cases, so any review would be appreciated.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@128545 91177308-0d34-0410-b5e6-96231b3b80d8
