This is the first patch in a series of patches to rename isNormal =>
isFiniteNonZero and isIEEENormal => isNormal. In order to prevent careless
errors on my part the overall plan is:
1. Add the isFiniteNonZero predicate with tests. I can do this in a method
independent of isNormal. (This step is this patch).
2. Convert all references to isNormal with isFiniteNonZero. My plan is to
comment out isNormal locally and continually convert isNormal references =>
isFiniteNonZero until llvm/clang compiles.
3. Remove old isNormal and rename isIEEENormal to isNormal.
4. Look through all of said references from patch 2 and see if we can simplify
them by using the new isNormal.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184350 91177308-0d34-0410-b5e6-96231b3b80d8
This allows the compiler to see the enum and warn about it. While in here,
fix a switch to not use a default and fix style violations.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184186 91177308-0d34-0410-b5e6-96231b3b80d8
Someone may want to do something crazy, like replace these objects if they
change or something.
No functionality change intended.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184175 91177308-0d34-0410-b5e6-96231b3b80d8
These APIs are still used, and the constant APIs are actually really important.
Removing these makes -Wdocumentation more useful.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184170 91177308-0d34-0410-b5e6-96231b3b80d8
The main advantages here are way better heuristics, taking into account not
just loop depth but also __builtin_expect and other static heuristics and will
eventually learn how to use profile info. Most of the work in this patch is
pushing the MachineBlockFrequencyInfo analysis into the right places.
This is good for a 5% speedup on zlib's deflate (x86_64), there were some very
unfortunate spilling decisions in its hottest loop in longest_match(). Other
benchmarks I tried were mostly neutral.
This changes register allocation in subtle ways, update the tests for it.
2012-02-20-MachineCPBug.ll was deleted as it's very fragile and the instruction
it looked for was gone already (but the FileCheck pattern picked up unrelated
stuff).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184105 91177308-0d34-0410-b5e6-96231b3b80d8
This patch also adds a simpler version of sys::fs::remove and a tool_output_file
constructor for when we already have an open file.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184095 91177308-0d34-0410-b5e6-96231b3b80d8
llvm-ar is the only tool that needs to write archive files. Every other tool
should be able to use the lib/Object interface.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184083 91177308-0d34-0410-b5e6-96231b3b80d8
llvm-objdump should provide some way of printing out the addends present in the
.rela sections for debugging purposes if nothing else.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184072 91177308-0d34-0410-b5e6-96231b3b80d8
Frame index handling is now target-agnostic, so delete the target hooks
for creation & asm printing of target-specific addressing in DBG_VALUEs
and any related functions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184067 91177308-0d34-0410-b5e6-96231b3b80d8
This currently unused function appeared to be asserting in the wrong
direction - DebugValues are never definitions of registers, only uses.
Curiously we don't perform any of these checks for the more common (&
actually used) case of MachineOperand::CreateReg (or other Create
functions).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184065 91177308-0d34-0410-b5e6-96231b3b80d8
Replace the ill-defined MinLatency and ILPWindow properties with
with straightforward buffer sizes:
MCSchedMode::MicroOpBufferSize
MCProcResourceDesc::BufferSize
These can be used to more precisely model instruction execution if desired.
Disabled some misched tests temporarily. They'll be reenabled in a few commits.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184032 91177308-0d34-0410-b5e6-96231b3b80d8
Archive files (.a) can have a symbol table indicating which object
files in them define which symbols. The purpose of this symbol table
is to speed up linking by allowing the linker the read only the .o
files it is actually going to use instead of having to parse every
object's symbol table.
LLVM's archive library currently supports a LLVM specific format for
such table. It is hard to see any value in that now that llvm-ld is
gone:
* System linkers don't use it: GNU ar uses the same plugin as the
linker to create archive files with a regular index. The OS X ar
creates no symbol table for IL files, I assume the linker just parses
all IL files.
* It doesn't interact well with archives having both IL and native objects.
* We probably don't want to be responsible for yet another archive
format variant.
This patch then:
* Removes support for creating and reading such index from lib/Archive.
* Remove llvm-ranlib, since there is nothing left for it to do.
We should in the future add support for regular indexes to llvm-ar for
both native and IL objects. When we do that, llvm-ranlib should be
reimplemented as a symlink to llvm-ar, as it is equivalent to "ar s".
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184019 91177308-0d34-0410-b5e6-96231b3b80d8
It looks like clang-tools-extra/unittests/cpp11-migrate/TransformTest.cpp
depends on the behaviour of the old one on Windows. Maybe a difference
between GetCurrentDirectoryA and GetCurrentDirectoryW?
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184009 91177308-0d34-0410-b5e6-96231b3b80d8
in functions which call __builtin_unwind_init()
__builtin_unwind_init() is an undocumented gcc intrinsic which has this effect,
and is used in libgcc_eh.
Goes part of the way toward fixing PR8541.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183984 91177308-0d34-0410-b5e6-96231b3b80d8
For consistency, change the address in the test case from 0xDEADBEEF to
0xCAFEBABE since 0xCAFEBABE that actually has a 2-byte alignment.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183962 91177308-0d34-0410-b5e6-96231b3b80d8
