When new virtual registers are created during splitting/spilling, defer
creation of the live interval until we need to use the live interval.
Along with the recent commits to notify LiveRangeEdit when new virtual
registers are created, this makes it possible for functions like
TargetInstrInfo::loadRegFromStackSlot() and
TargetInstrInfo::storeRegToStackSlot() to create multiple virtual
registers as part of the process of generating loads/stores for
different register classes, and then have the live intervals for those
new registers computed when they are needed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188437 91177308-0d34-0410-b5e6-96231b3b80d8
MachineInstrSpan is initialized with a MachineBasicBlock::iterator,
and is intended to track which instructions are inserted before/after
that instruction from the time the MachineInstrSpan is created.
It provides a begin()/end() interface to walk the range of
instructions inserted around the initial instruction (including that
initial instruction).
It also provides a getInitial() interface to return the initial
iterator.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188436 91177308-0d34-0410-b5e6-96231b3b80d8
Add a delegate class to MachineRegisterInfo with a single virtual
function, MRI_NoteNewVirtualRegister(). Update LiveRangeEdit to inherit
from this delegate class and override the definition of the callback
with an implementation that tracks the newly created virtual registers.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188435 91177308-0d34-0410-b5e6-96231b3b80d8
Track new virtual registers by register number, rather than by the live
interval created for them. This is the first step in separating the
creation of new virtual registers and new live intervals. Eventually
live intervals will be created and populated on demand after the virtual
registers have been created and used in instructions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188434 91177308-0d34-0410-b5e6-96231b3b80d8
This replaces the old incomplete greylist functionality with an ABI
list, which can provide more detailed information about the ABI and
semantics of specific functions. The pass treats every function in
the "uninstrumented" category in the ABI list file as conforming to
the "native" (i.e. unsanitized) ABI. Unless the ABI list contains
additional categories for those functions, a call to one of those
functions will produce a warning message, as the labelling behaviour
of the function is unknown. The other supported categories are
"functional", "discard" and "custom".
- "discard" -- This function does not write to (user-accessible) memory,
and its return value is unlabelled.
- "functional" -- This function does not write to (user-accessible)
memory, and the label of its return value is the union of the label of
its arguments.
- "custom" -- Instead of calling the function, a custom wrapper __dfsw_F
is called, where F is the name of the function. This function may wrap
the original function or provide its own implementation.
Differential Revision: http://llvm-reviews.chandlerc.com/D1345
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188402 91177308-0d34-0410-b5e6-96231b3b80d8
It's useful to be able to write down floating-point numbers without having to
worry about what they'll be rounded to (as C99 discovered), this extends that
ability to the MC assembly parsers.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188370 91177308-0d34-0410-b5e6-96231b3b80d8
However, opt -O2 doesn't run mem2reg directly so nobody noticed until r188146
when SROA started sending more things directly down the PromoteMemToReg path.
In order to revert r187191, I also revert dependent revisions r187296, r187322
and r188146. Fixes PR16867. Does not add the testcases from that PR, but both
of them should get added for both mem2reg and sroa when this revert gets
unreverted.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188327 91177308-0d34-0410-b5e6-96231b3b80d8
Added v8f16 to ValueTypes.h, ValueTypes.cpp, ValueTypes.td,
and CodeGenTarget.cpp
Patch by Daniel Sanders
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188326 91177308-0d34-0410-b5e6-96231b3b80d8
This adds KIND_REMAINING_ARGS, a class of options that consume
all remaining arguments on the command line.
This will be used to support /link in clang-cl, which is used
to forward all remaining arguments to the linker.
It also allows us to remove the hard-coded handling of "--",
allowing clients (clang and lld) to implement that functionality
themselves with this new option class.
Differential Revision: http://llvm-reviews.chandlerc.com/D1387
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188314 91177308-0d34-0410-b5e6-96231b3b80d8
LowerCallTo returns a pair with the return value of the call as the first
element and the chain associated with the return value as the second element. If
we lower a call that has a void return value, LowerCallTo returns an SDValue
with a NULL SDNode and the chain for the call. Thus makeLibCall by just
returning the first value makes it impossible for you to set up the chain so
that the call is not eliminated as dead code.
I also updated all references to makeLibCall to reflect the new return type.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188300 91177308-0d34-0410-b5e6-96231b3b80d8
to find loops if the From and To instructions were in the same block.
Refactor the code a little now that we need to fill to start the CFG-walking
algorithm with more than one starting basic block sometimes.
Special thanks to Andrew Trick for catching an error in my understanding of
natural loops in code review.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188236 91177308-0d34-0410-b5e6-96231b3b80d8
In order to appease people (in Apple) who accuse me for committing "huge change" (?) without proper review.
Thank Eric for fixing a compile-warning.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188204 91177308-0d34-0410-b5e6-96231b3b80d8
1. Add some helper classes for partitions. They are designed in a
way such that the top-level LTO driver will not see much difference
with or without partitioning.
2. Introduce work-dir. Now all intermediate files generated during
LTO phases will be saved under work-dir. User can specify the workdir
via -lto-workdir=/path/to/dir. By default the work-dir will be
erased before linker exit. To keep the workdir, do -lto-keep, or -lto-keep=1.
TODO: Erase the workdir, if the linker exit prematurely.
We are currently not able to remove directory on signal. The support
routines simply ignore directory.
3. Add one new API lto_codegen_get_files_need_remove().
Linker and LTO plugin will communicate via this API about which files
(including directories) need to removed before linker exit.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188188 91177308-0d34-0410-b5e6-96231b3b80d8
curses.h). Finding these headers is next to impossible. For example, on
Debian systems libtinfo-dev provides the terminfo reading library we
want, but *not* term.h. For the header, you have to use libncurses-dev.
And libncursesw-dev provides a *different* term.h in a different
location!
These headers aren't worth it. We want two functions the signatures of
which are clearly spec'ed in sys-v and other documentation. Just declare
them ourselves and call them. This should fix some debian builders and
provide better support for "minimal" debian systems that do want color
autodetection.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188165 91177308-0d34-0410-b5e6-96231b3b80d8
For now this is restricted to fixed-length comparisons with a length
in the range [1, 256], as for memcpy() and MVC.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188163 91177308-0d34-0410-b5e6-96231b3b80d8
library for color support detection. This still will use a curses
library if that is all we have available on the system. This change
tries to use a smaller subset of the curses library, specifically the
subset that is on some systems split off into a separate library. For
example, if you install ncurses configured --with-tinfo, a 'libtinfo' is
install that provides just the terminfo querying functionality. That
library is now used instead of curses when it is available.
This happens to fix a build error on systems with that library because
when we tried to link ncurses into the binary, we didn't pull tinfo in
as well. =]
It should also provide an easy path for supporting the NetBSD
libterminfo library, but as I don't have access to a NetBSD system I'm
leaving adding that support to those folks.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188160 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Doing work in constructors is bad: this change suggests to
call SpecialCaseList::create(Path, Error) instead of
"new SpecialCaseList(Path)". Currently the latter may crash with
report_fatal_error, which is undesirable - sometimes we want to report
the error to user gracefully - for example, if he provides an incorrect
file as an argument of Clang's -fsanitize-blacklist flag.
Reviewers: pcc
Reviewed By: pcc
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1327
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188156 91177308-0d34-0410-b5e6-96231b3b80d8
Use it to avoid repeating ourselves too often. Also store MVT::SimpleValueType
in the TTI tables so they can be statically initialized, MVT's constructors
create bloated initialization code otherwise.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188095 91177308-0d34-0410-b5e6-96231b3b80d8
This is necessary to allow Clang to only emit implicit members when
there is code generated for them, rather than whenever they are ODR
used.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188082 91177308-0d34-0410-b5e6-96231b3b80d8
This trades some complexity in operator== for not introducing static objects
into any functions using recursive directory iterators.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188081 91177308-0d34-0410-b5e6-96231b3b80d8
The compiler was warning about using | on a uintptr_t and bool:
Object/ELFObjectFile.h(131) : warning C4805: '|' : unsafe
mix of type 'uintptr_t' and type 'bool' in operation
I think the warning might be useful in other cases, so I added
a cast instead of disabling it altogether.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188079 91177308-0d34-0410-b5e6-96231b3b80d8
Currently, when an invalid attribute is encountered on processing a .s file,
clang will abort due to llvm_unreachable. Invalid user input should not cause
an abnormal termination of the compiler. Change the interface to return a
boolean to indicate the failure as a first step towards improving hanlding of
malformed user input to clang.
Signed-off-by: Saleem Abdulrasool <compnerd@compnerd.org>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188047 91177308-0d34-0410-b5e6-96231b3b80d8
* ELFTypes.h contains template magic for defining types based on endianess, size, and alignment.
* ELFFile.h defines the ELFFile class which provides low level ELF specific access.
* ELFObjectFile.h contains ELFObjectFile which uses ELFFile to implement the ObjectFile interface.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188022 91177308-0d34-0410-b5e6-96231b3b80d8
this records relocation entries in the mach-o object file
for PIC code generation.
tested on powerpc-darwin8, validated against darwin otool -rvV
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188004 91177308-0d34-0410-b5e6-96231b3b80d8
All libm floating-point rounding functions, except for round(), had their own
ISD nodes. Recent PowerPC cores have an instruction for round(), and so here I'm
adding ISD::FROUND so that round() can be custom lowered as well.
For the most part, this is straightforward. I've added an intrinsic
and a matching ISD node just like those for nearbyint() and friends. The
SelectionDAG pattern I've named frnd (because ISD::FP_ROUND has already claimed
fround).
This will be used by the PowerPC backend in a follow-up commit.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187926 91177308-0d34-0410-b5e6-96231b3b80d8
DataFlowSanitizer is a generalised dynamic data flow analysis.
Unlike other Sanitizer tools, this tool is not designed to detect a
specific class of bugs on its own. Instead, it provides a generic
dynamic data flow analysis framework to be used by clients to help
detect application-specific issues within their own code.
Differential Revision: http://llvm-reviews.chandlerc.com/D965
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187923 91177308-0d34-0410-b5e6-96231b3b80d8
r187874 seems to have been missed by the build bot infrastructure, and
the subsequent commits to compiler-rt don't seem to be queuing up new
build requsets. Hopefully this will.
As it happens, having the space here is the more common formatting. =]
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187879 91177308-0d34-0410-b5e6-96231b3b80d8
using it to detect whether or not a terminal supports colors. This
replaces a particularly egregious hack that merely compared the TERM
environment variable to "dumb". That doesn't really translate to
a reasonable experience for users that have actually ensured their
terminal's capabilities are accurately reflected.
This makes testing a terminal for color support somewhat more expensive,
but it is called very rarely anyways. The important fast path when the
output is being piped somewhere is already in place.
The global lock may seem excessive, but the spec for calling into curses
is *terrible*. The whole library is terrible, and I spent quite a bit of
time looking for a better way of doing this before convincing myself
that this was the fundamentally correct way to behave. The damage of the
curses library is very narrowly confined, and we continue to use raw
escape codes for actually manipulating the colors which is a much sane
system than directly using curses here (IMO).
If this causes trouble for folks, please let me know. I've tested it on
Linux and will watch the bots carefully. I've also worked to account for
the variances of curses interfaces that I could finde documentation for,
but that may not have been sufficient.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187874 91177308-0d34-0410-b5e6-96231b3b80d8
lld has a hashtable with StringRef keys; it needs to iterate over the keys in
*insertion* order. This is currently implemented as std::vector<StringRef> +
DenseMap<StringRef, T>. This will probably need a proper
DenseMapInfo<StringRef> if we don't want to lose memory/performance by
migrating to a different data structure.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187868 91177308-0d34-0410-b5e6-96231b3b80d8
for StringRef with a StringMap
The bug is that the empty key compares equal to the tombstone key.
Also added an assertion to DenseMap to catch similar bugs in future.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187866 91177308-0d34-0410-b5e6-96231b3b80d8
Previously this check was guarded by MSVC, which doesn't distinguish
between the compiler and the headers/library. This enables clang to
compile more of LLVM on Windows with Microsoft headers.
Remove some unused macros while I'm here: error_t and LTDL stuff.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187839 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This is a second attempt to get this right. After reading the Unicode
Standard I came up with the code that uses definitions of "printable" and
"column width" more suitable for terminal output (i.e. fixed-width fonts and
special treatment of many control characters).
The implementation here can probably be used for Windows and MacOS if someone
can test it properly.
The patch addresses PR14910.
Reviewers: jordan_rose, gribozavr
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1253
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187837 91177308-0d34-0410-b5e6-96231b3b80d8
Also remove checking of llvm.dbg.sp since it is not used in generating dwarf.
Current state of Finder:
DebugInfoFinder tries to list all debug info MDNodes used in a module. To
list debug info MDNodes used by an instruction, DebugInfoFinder provides
processDeclare, processValue and processLocation to handle DbgDeclareInst,
DbgValueInst and DbgLoc attached to instructions. processModule will go
through all DICompileUnits in llvm.dbg.cu and list debug info MDNodes
used by the CUs.
TODO:
1> Finder has a list of CUs, SPs, Types, Scopes and global variables. We
need to add a list of variables that are used by DbgDeclareInst and
DbgValueInst.
2> MDString fields should be null or isa<MDString> and MDNode fields should be
null or isa<MDNode>. We currently use empty string or int 0 to represent null.
3> Go though Verify functions and make sure that they check field types.
4> Clean up existing testing cases to remove llvm.dbg.sp and make sure each
testing case has a llvm.dbg.cu.
Re-apply r187609 with fix to pass ocaml binding. vmcore.ml generates a debug
location with scope being metadata !{}, in verifier we treat this as a null
scope.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187812 91177308-0d34-0410-b5e6-96231b3b80d8
This change came about primarily because of two issues in the existing code.
Niether of:
define i64 @test1(i64 %val) {
%in = trunc i64 %val to i32
tail call i32 @ret32(i32 returned %in)
ret i64 %val
}
define i64 @test2(i64 %val) {
tail call i32 @ret32(i32 returned undef)
ret i32 42
}
should be tail calls, and the function sameNoopInput is responsible. The main
problem is that it is completely symmetric in the "tail call" and "ret" value,
but in reality different things are allowed on each side.
For these cases:
1. Any truncation should lead to a larger value being generated by "tail call"
than needed by "ret".
2. Undef should only be allowed as a source for ret, not as a result of the
call.
Along the way I noticed that a mismatch between what this function treats as a
valid truncation and what the backends see can lead to invalid calls as well
(see x86-32 test case).
This patch refactors the code so that instead of being based primarily on
values which it recurses into when necessary, it starts by inspecting the type
and considers each fundamental slot that the backend will see in turn. For
example, given a pathological function that returned {{}, {{}, i32, {}}, i32}
we would consider each "real" i32 in turn, and ask if it passes through
unchanged. This is much closer to what the backend sees as a result of
ComputeValueVTs.
Aside from the bug fixes, this eliminates the recursion that's going on and, I
believe, makes the bulk of the code significantly easier to understand. The
trade-off is the nasty iterators needed to find the real types inside a
returned value.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187787 91177308-0d34-0410-b5e6-96231b3b80d8
This virtual function can be implemented by targets to specify the type
to use for the index operand of INSERT_VECTOR_ELT, EXTRACT_VECTOR_ELT,
INSERT_SUBVECTOR, EXTRACT_SUBVECTOR. The default implementation returns
the result from TargetLowering::getPointerTy()
The previous code was using TargetLowering::getPointerTy() for vector
indices, because this is guaranteed to be legal on all targets. However,
using TargetLowering::getPointerTy() can be a problem for targets with
pointer sizes that differ across address spaces. On such targets,
when vectors need to be loaded or stored to an address space other than the
default 'zero' address space (which is the address space assumed by
TargetLowering::getPointerTy()), having an index that
is a different size than the pointer can lead to inefficient
pointer calculations, (e.g. 64-bit adds for a 32-bit address space).
There is no intended functionality change with this patch.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187748 91177308-0d34-0410-b5e6-96231b3b80d8
Our internal regex implementation does not cope with large numbers
of anchors very efficiently. Given a ~3600-entry special case list,
regex compilation can take on the order of seconds. This patch solves
the problem for the special case of patterns matching literal global
names (i.e. patterns with no regex metacharacters). Rather than
forming regexes from literal global name patterns, add them to
a StringSet which is checked before matching against the regex.
This reduces regex compilation time by an order of roughly thousands
when reading the aforementioned special case list, according to a
completely unscientific study.
No test cases. I figure that any new tests for this code should
check that regex metacharacters are properly recognised. However,
I could not find any documentation which documents the fact that the
syntax of global names in special case lists is based on regexes.
The extent to which regex syntax is supported in special case lists
should probably be decided on/documented before writing tests.
Differential Revision: http://llvm-reviews.chandlerc.com/D1150
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187732 91177308-0d34-0410-b5e6-96231b3b80d8
Recent versions of the OS X linker support this but follow the existing
OS X linker convention of using an underscore in the option name, i.e.,
-export_dynamic. Rather than changing our configure scripts to check for
that alternate spelling, it is simpler to just use the compiler's -rdynamic
option and let it deal with translating that to the appropriate linker
option. One potential disadvantage of this approach is that the compiler
will typically ignore -rdynamic on platforms where it is not supported, so
the HAVE_LINK_EXPORT_DYNAMIC in config.h will not necessarily show whether
that option has any effect or not. I don't see any in-tree uses of that
macro, so I'm assuming it is OK.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187686 91177308-0d34-0410-b5e6-96231b3b80d8
Function attributes are the future! So just query whether we want to realign the
stack directly from the function instead of through a random target options
structure.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187618 91177308-0d34-0410-b5e6-96231b3b80d8
The use of sd_dev and st_ino has reached libclang, so expose the two components
in UniqueID so that we can use it in clang.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187616 91177308-0d34-0410-b5e6-96231b3b80d8
Also remove checking of llvm.dbg.sp since it is not used in generating dwarf.
Current state of Finder:
DebugInfoFinder tries to list all debug info MDNodes used in a module. To
list debug info MDNodes used by an instruction, DebugInfoFinder provides
processDeclare, processValue and processLocation to handle DbgDeclareInst,
DbgValueInst and DbgLoc attached to instructions. processModule will go
through all DICompileUnits in llvm.dbg.cu and list debug info MDNodes
used by the CUs.
TODO:
1> Finder has a list of CUs, SPs, Types, Scopes and global variables. We
need to add a list of variables that are used by DbgDeclareInst and
DbgValueInst.
2> MDString fields should be null or isa<MDString> and MDNode fields should be
null or isa<MDNode>. We currently use empty string or int 0 to represent null.
3> Go though Verify functions and make sure that they check field types.
4> Clean up existing testing cases to remove llvm.dbg.sp and make sure each
testing case has a llvm.dbg.cu.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187609 91177308-0d34-0410-b5e6-96231b3b80d8
Patch by Ana Pazos.
- Completed implementation of instruction formats:
AdvSIMD three same
AdvSIMD modified immediate
AdvSIMD scalar pairwise
- Completed implementation of instruction classes
(some of the instructions in these classes
belong to yet unfinished instruction formats):
Vector Arithmetic
Vector Immediate
Vector Pairwise Arithmetic
- Initial implementation of instruction formats:
AdvSIMD scalar two-reg misc
AdvSIMD scalar three same
- Intial implementation of instruction class:
Scalar Arithmetic
- Initial clang changes to support arm v8 intrinsics.
Note: no clang changes for scalar intrinsics function name mangling yet.
- Comprehensive test cases for added instructions
To verify auto codegen, encoding, decoding, diagnosis, intrinsics.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187567 91177308-0d34-0410-b5e6-96231b3b80d8
The following are made available by clang in the XCore ABI
__builtin_bitrev
__builtin_getid
__builtin_getps
__builtin_setps
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187566 91177308-0d34-0410-b5e6-96231b3b80d8
This makes option aliases more powerful by enabling them to
pass along arguments to the option they're aliasing.
For example, if we have a joined option "-foo=", we can now
specify a flag option "-bar" to be an alias of that, with the
argument "baz".
This is especially useful for the cl.exe compatible clang driver,
where many options are aliases. For example, this patch enables
us to alias "/Ox" to "-O3" (-O is a joined option), and "/WX" to
"-Werror" (again, -W is a joined option).
Differential Revision: http://llvm-reviews.chandlerc.com/D1245
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187537 91177308-0d34-0410-b5e6-96231b3b80d8
It will now only convert the arguments / return value and call
the underlying function if the types are able to be bitcasted.
This avoids using fp<->int conversions that would occur before.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187444 91177308-0d34-0410-b5e6-96231b3b80d8
When registers must be live throughout the scheduling region, increase
the limit for the register class. Once we exceed the original limit,
they will be spilled, and there's no point further reducing pressure.
This isn't a perfect heuristics but avoids a situation where the
scheduler could become trapped by trying to achieve the impossible.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187436 91177308-0d34-0410-b5e6-96231b3b80d8
32-bit symbols have "_" as global prefix, but when forming the name of
COMDAT sections this prefix is ignored. The current behavior assumes that
this prefix is always present which is not the case for 64-bit and names
are truncated.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187356 91177308-0d34-0410-b5e6-96231b3b80d8
If no other operation is specified, 's' becomes an operation instead of an
modifier. The s operation just creates a symbol table. It is the same as
running ranlib.
We assume the archive was created by a sane ar (like llvm-ar or gnu ar) and
if the symbol table is present, then it is current. We use that to optimize
the most common case: a broken build system that thinks it has to run ranlib.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187353 91177308-0d34-0410-b5e6-96231b3b80d8
standards for LLVM. Remove duplicated comments on the interface from the
implementation file (implementation comments are left there of course).
Also clean up, re-word, and fix a few typos and errors in the commenst
spotted along the way.
This is in preparation for changes to these files and to keep the
uninteresting tidying in a separate commit.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187335 91177308-0d34-0410-b5e6-96231b3b80d8
useful in a subsequent patch, but causes an unfortunate amount of noise,
so I pulled it out into a separate patch.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187322 91177308-0d34-0410-b5e6-96231b3b80d8
Adds unit tests for it too.
Split BasicBlockUtils into an analysis-half and a transforms-half, and put the
analysis bits into a new Analysis/CFG.{h,cpp}. Promote isPotentiallyReachable
into llvm::isPotentiallyReachable and move it into Analysis/CFG.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187283 91177308-0d34-0410-b5e6-96231b3b80d8
Merge consecutive if-regions if they contain identical statements.
Both transformations reduce number of branches. The transformation
is guarded by a target-hook, and is currently enabled only for +R600,
but the correctness has been tested on X86 target using a variety of
CPU benchmarks.
Patch by: Mei Ye
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187278 91177308-0d34-0410-b5e6-96231b3b80d8
These were reverted in r167222 along with the rest
of the last different address space pointer size attempt.
These will be used in later commits.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187223 91177308-0d34-0410-b5e6-96231b3b80d8
On Windows, this improves clean cmake configuration time on my
workstation from 1m58s to 1m32s, which is pretty significant. There's
probably more that can be done here, but this is the low hanging fruit.
Eric volunteered to regenerate ./configure for me.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187209 91177308-0d34-0410-b5e6-96231b3b80d8
The bitcode representation attribute kinds are encoded into / decoded from
should be independent of the current set of LLVM attributes and their position
in the AttrKind enum. This patch explicitly encodes attributes to fixed bitcode
values.
With this patch applied, LLVM does not silently misread attributes written by
LLVM 3.3. We also enhance the decoding slightly such that an error message is
printed if an unknown AttrKind encoding was dected.
Bonus: Dropping bitcode attributes from AttrKind is now easy, as old AttrKinds
do not need to be kept to support the Bitcode reader.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187186 91177308-0d34-0410-b5e6-96231b3b80d8
This patch provides basic support for powerpc64le as an LLVM target.
However, use of this target will not actually generate little-endian
code. Instead, use of the target will cause the correct little-endian
built-in defines to be generated, so that code that tests for
__LITTLE_ENDIAN__, for example, will be correctly parsed for
syntax-only testing. Code generation will otherwise be the same as
powerpc64 (big-endian), for now.
The patch leaves open the possibility of creating a little-endian
PowerPC64 back end, but there is no immediate intent to create such a
thing.
The LLVM portions of this patch simply add ppc64le coverage everywhere
that ppc64 coverage currently exists. There is nothing of any import
worth testing until such time as little-endian code generation is
implemented. In the corresponding Clang patch, there is a new test
case variant to ensure that correct built-in defines for little-endian
code are generated.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187179 91177308-0d34-0410-b5e6-96231b3b80d8
The language reference says that:
"If a symbol appears in the @llvm.used list, then the compiler,
assembler, and linker are required to treat the symbol as if there is
a reference to the symbol that it cannot see"
Since even the linker cannot see the reference, we must assume that
the reference can be using the symbol table. For example, a user can add
__attribute__((used)) to a debug helper function like dump and use it from
a debugger.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187103 91177308-0d34-0410-b5e6-96231b3b80d8
There's no need to specify a flag to omit frame pointer elimination on non-leaf
nodes...(Honestly, I can't parse that option out.) Use the function attribute
stuff instead.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187093 91177308-0d34-0410-b5e6-96231b3b80d8
This removes the need to store the asm variant in each row of the single table that existed before. Shaves ~16K off the size of X86AsmParser.o.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187026 91177308-0d34-0410-b5e6-96231b3b80d8
Similar to ARM change r182800, dynamic linker will read bits/addends from
the original object rather than from the object that might have been patched
previously. For the purpose of relocations for MCJIT stubs on MIPS, we
internally use otherwise unused MIPS relocations.
The change also enables MCJIT unit tests for MIPS (EL/BE), and the following
two tests now pass:
- MCJITTest.return_global and
- MCJITTest.multiple_functions.
These issues have been tracked as Bug 16250.
Patch by Petar Jovanovic.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187019 91177308-0d34-0410-b5e6-96231b3b80d8
This commit also implements these functions for R600 and removes a test
case that was relying on the buggy behavior.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187007 91177308-0d34-0410-b5e6-96231b3b80d8
The main observation is that we never need both the filesize and the map size.
When mapping a slice of a file, it doesn't make sense to request a null
terminator and that would be the only case where the filesize would be used.
There are other cleanups that should be done in this area:
* A client should not have to pass the size (even an explicit -1) to say if
it wants a null terminator or not, so we should probably swap the argument
order.
* The default should be to not require a null terminator. Very few clients
require this, but many end up asking for it just because it is the default.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186984 91177308-0d34-0410-b5e6-96231b3b80d8
MDNodes used by DbgDeclareInst and DbgValueInst.
Another 16 testing cases failed and they are disabled with
-disable-debug-info-verifier.
A total of 34 cases are disabled with -disable-debug-info-verifier and will be
corrected.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186902 91177308-0d34-0410-b5e6-96231b3b80d8
Use the function attributes to pass along the stack protector buffer size.
Now that we have robust function attributes, don't use a command line option to
specify the stack protecto buffer size.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186863 91177308-0d34-0410-b5e6-96231b3b80d8
Variadic MC instructions don't note whether the variable operands
are uses or defs, so mayAffectControlFlow() must conservatively
assume they are defs and return true if the PC is in the operand
list.
rdar://14488628
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186846 91177308-0d34-0410-b5e6-96231b3b80d8
