ErrorOr<void> represents an operation that returns nothing, but can still fail.
It should be used in cases where you need the aditional user data that ErrorOr
provides over error_code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173209 91177308-0d34-0410-b5e6-96231b3b80d8
This is a follow-up to r171845, which fixes the same issue in the Support code.
Only targets with >256 relocations (principally AArch64) should be affected.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173151 91177308-0d34-0410-b5e6-96231b3b80d8
but I cannot reproduce the problem and have scrubed my sources and
even tested with llvm-lit -v --vg.
Support for Mips register information sections.
Mips ELF object files have a section that is dedicated
to register use info. Some of this information such as
the assumed Global Pointer value is used by the linker
in relocation resolution.
The register info file is .reginfo in o32 and .MIPS.options
in 64 and n32 abi files.
This patch contains the changes needed to create the sections,
but leaves the actual register accounting for a future patch.
Contributer: Jack Carter
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172847 91177308-0d34-0410-b5e6-96231b3b80d8
In r143502, we renamed getHostTriple() to getDefaultTargetTriple()
as part of work to allow the user to supply a different default
target triple at configure time. This change also affected the JIT.
However, it is inappropriate to use the default target triple in the
JIT in most circumstances because this will not necessarily match
the current architecture used by the process, leading to illegal
instruction and other such errors at run time.
Introduce the getProcessTriple() function for use in the JIT and
its clients, and cause the JIT to use it. On architectures with a
single bitness, the host and process triples are identical. On other
architectures, the host triple represents the architecture of the
host CPU, while the process triple represents the architecture used
by the host CPU to interpret machine code within the current process.
For example, when executing 32-bit code on a 64-bit Linux machine,
the host triple may be 'x86_64-unknown-linux-gnu', while the process
triple may be 'i386-unknown-linux-gnu'.
This fixes JIT for the 32-on-64-bit (and vice versa) build on non-Apple
platforms.
Differential Revision: http://llvm-reviews.chandlerc.com/D254
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172627 91177308-0d34-0410-b5e6-96231b3b80d8
Like Clang's FixItHint, SMFixIt represents an insertion, replacement, or
removal of source text. One or more fix-its can be emitted as part of
a diagnostic, and will be printed below the source range line to show the
user how they can fix their code.
Currently, the only client of SMFixIt is clang-tblgen; thus, the tests for
this behavior live in clang/test/TableGen/tg-fixits.td. If/when SMFixIt is
adopted within LLVM itself, those tests should be moved to the LLVM suite.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172086 91177308-0d34-0410-b5e6-96231b3b80d8
into a new function llvm::sys::PrintStackTrace, so that it's available to clients for logging purposes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171989 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adjust the r171506 to make all DWARF enconding pc-relative
for PPC64. It also adds the R_PPC64_REL32 relocation handling in MCJIT
(since the eh_frame will not generate PIC-relative relocation) and also
adds the emission of stubs created by the TTypeEncoding.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171979 91177308-0d34-0410-b5e6-96231b3b80d8
Stop using BumpPtrAllocator for HNodes because
they have fields (vector, map) which require HNode
destructors to be run.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171896 91177308-0d34-0410-b5e6-96231b3b80d8
This is necessary not only for representing empty ranges, but for handling
multibyte characters in the input. (If the end pointer in a range refers to
a multibyte character, should it point to the beginning or the end of the
character in a char array?) Some of the code in the asm parsers was already
assuming this anyway.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171765 91177308-0d34-0410-b5e6-96231b3b80d8
turning a code like this:
if (foo)
free(foo)
into that:
free(foo)
Move a call to free from basic block FB into FB's predecessor, P,
when the path from P to FB is taken only if the argument of free is
not equal to NULL.
Some restrictions apply on P and FB to be sure that this code motion
is profitable. Namely:
1. FB must have only one predecessor P.
2. FB must contain only the call to free plus an unconditional
branch to S.
3. P's successors are FB and S.
Because of 1., we will not increase the code size when moving the call
to free from FB to P.
Because of 2., FB will be empty after the move.
Because of 2. and 3., P's branch instruction becomes useless, so as FB
(simplifycfg will do the job).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171762 91177308-0d34-0410-b5e6-96231b3b80d8
This is similar to the existing Recycler allocator, but instead of
recycling individual objects from a BumpPtrAllocator, arrays of
different sizes can be allocated.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171581 91177308-0d34-0410-b5e6-96231b3b80d8
if-ed out code paths and on Windows. Hopefully restores the Windows
build. Thanks to Reid Kleckner for helping triage this.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171568 91177308-0d34-0410-b5e6-96231b3b80d8
wall time, user time, and system time since a process started.
For walltime, we currently use TimeValue's interface and a global
initializer to compute a close approximation of total process runtime.
For user time, this adds support for an somewhat more precise timing
mechanism -- clock_gettime with the CLOCK_PROCESS_CPUTIME_ID clock
selected.
For system time, we have to do a full getrusage call to extract the
system time from the OS. This is expensive but unavoidable.
In passing, clean up the implementation of the old APIs and fix some
latent bugs in the Windows code. This might have manifested on Windows
ARM systems or other systems with strange 64-bit integer behavior.
The old API for this both user time and system time simultaneously from
a single getrusage call. While this results in fewer system calls, it
also results in a lower precision user time and if only user time is
desired, it introduces a higher overhead. It may be worthwhile to switch
some of the pass timers to not track system time and directly track user
and wall time. The old API also tracked walltime in a confusing way --
it just set it to the current walltime rather than providing any measure
of wall time since the process started the way buth user and system time
are tracked. The new API is more consistent here.
The plan is to eventually implement these methods for a *child* process
by using the wait3(2) system call to populate an rusage struct
representing the whole subprocess execution. That way, after waiting on
a child process its stats will become accurate and cheap to query.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171551 91177308-0d34-0410-b5e6-96231b3b80d8
A BumpPtrAllocator has an empty Deallocate() method, but
Recycler::clear() would still call it for every single object ever
allocated, bringing all those objects into cache. As a bonus,
iplist::remove() will also write to the Prev/Next pointers on all the
objects, so all those cache lines have to be written back to RAM before
the pages are given back to the OS.
Stop wasting time and memory bandwith by using the new
clearAndLeakUnsafely() function to jettison all the recycled objects.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171541 91177308-0d34-0410-b5e6-96231b3b80d8
This patch fixes the PPC eh_frame definitions for the personality and
frame unwinding for PIC objects. It makes PIC build correctly creates
relative relocations in the '.rela.eh_frame' segments and thus avoiding
a text relocation that generates a DT_TEXTREL segments in link phase.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171506 91177308-0d34-0410-b5e6-96231b3b80d8
Users of LLVM_BUILTIN_UNREACHABLE should be responsible in the case when LLVM_BUILTIN_UNREACHABLE is undefined.
Actually, (0, (p)) in LLVM_ASSUME_ALIGNED(p, a) caused thousands of warnings on g++-4.4. It was a motivation in this commit.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171455 91177308-0d34-0410-b5e6-96231b3b80d8
* Add support for specifying the alignment to use.
* Add the concept of native endianness. Used for unaligned native types.
The native alignment and read/write simplification is based on a patch by Richard Smith.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171406 91177308-0d34-0410-b5e6-96231b3b80d8
into their new header subdirectory: include/llvm/IR. This matches the
directory structure of lib, and begins to correct a long standing point
of file layout clutter in LLVM.
There are still more header files to move here, but I wanted to handle
them in separate commits to make tracking what files make sense at each
layer easier.
The only really questionable files here are the target intrinsic
tablegen files. But that's a battle I'd rather not fight today.
I've updated both CMake and Makefile build systems (I think, and my
tests think, but I may have missed something).
I've also re-sorted the includes throughout the project. I'll be
committing updates to Clang, DragonEgg, and Polly momentarily.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171366 91177308-0d34-0410-b5e6-96231b3b80d8
through the static helper functions. This is already true throughout the
codebase.
Slowly, I'm going to re-implement these static helpers in terms of a new
process based interface which can expose more information, and remove
the program object entirely.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171335 91177308-0d34-0410-b5e6-96231b3b80d8
Implement the old API in terms of the new one. This simplifies the
implementation on Windows which can now re-use the self_process's once
initialization.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171330 91177308-0d34-0410-b5e6-96231b3b80d8
a union. These don't actually work for by-value function arguments, and
MSVC warns if they exist even while (we hope) it aligns the argument
correctly due to the other union member.
This means MSVC will miss out on optimizations based on the alignment of
the buffer, but really, there aren't that many for x86 and MSVC is
likely not doing a great job of optimizing LLVM and Clang anyways.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171328 91177308-0d34-0410-b5e6-96231b3b80d8
