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
