This reverts commit r246044.
Build broken, still. It builds for me...
From: Mehdi Amini <mehdi.amini@apple.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246049 91177308-0d34-0410-b5e6-96231b3b80d8
We removed access to the DataLayout on the TargetMachine and
deprecated the C API function LLVMGetTargetMachineData() in r243114.
However the way I tried to be backward compatible was broken: I
changed the wrapper of the TargetMachine to be a structure that
includes the DataLayout as well. However the TargetMachine is also
wrapped by the ExecutionEngine, in the more classic way. A client
using the TargetMachine wrapped by the ExecutionEngine and trying
to get the DataLayout would break.
It seems tricky to solve the problem completely in the C API
implementation. This patch tries to address this backward
compatibility in a more lighter way in the C++ API. The C API is
restored in its original state and the removed C++ API is
reintroduced, but privately. The C API is friended to the
TargetMachine and should be the only consumer for this API.
Reviewers: ributzka
Differential Revision: http://reviews.llvm.org/D12263
From: Mehdi Amini <mehdi.amini@apple.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246044 91177308-0d34-0410-b5e6-96231b3b80d8
If you're going to realign %sp to get object alignment properly (which
the code does), and stack offsets and alignments are calculated going
down from %fp (which they are), then the total stack size had better
be a multiple of the alignment. LLVM did indeed ensure that.
And then, after aligning, the sparc frame code added 96 (for sparcv8)
to the frame size, making any requested alignment of 64-bytes or
higher *guaranteed* to be misaligned. The test case added with r245668
even tests this exact scenario, and asserted the incorrect behavior,
which I somehow failed to notice. D'oh.
This change fixes the frame lowering code to align the stack size
*after* adding the spill area, instead.
Differential Revision: http://reviews.llvm.org/D12349
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246042 91177308-0d34-0410-b5e6-96231b3b80d8
This is a fix for disassembling unusual instruction sequences in 64-bit
mode w.r.t the CALL rel16 instruction. It might be desirable to move the
check somewhere else, but it essentially mimics the special case
handling with JCXZ in 16-bit mode.
The current behavior accepts the opcode size prefix and causes the
call's immediate to stop disassembling after 2 bytes. When debugging
sequences of instructions with this pattern, the disassembler output
becomes extremely unreliable and essentially useless (if you jump midway
into what lldb thinks is a unified instruction, you'll lose %rip). So we
ignore the prefix and consume all 4 bytes when disassembling a 64-bit
mode binary.
Note: in Vol. 2A 3-99 the Intel spec states that CALL rel16 is N.S. N.S.
is defined as:
Indicates an instruction syntax that requires an address override
prefix in 64-bit mode and is not supported. Using an address
override prefix in 64-bit mode may result in model-specific
execution behavior. (Vol. 2A 3-7)
Since 0x66 is an operand override prefix we should be OK (although we
may want to warn about 0x67 prefixes to 0xe8). On the CPUs I tested
with, they all ignore the 0x66 prefix in 64-bit mode.
Patch by Matthew Barney!
Differential Revision: http://reviews.llvm.org/D9573
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246038 91177308-0d34-0410-b5e6-96231b3b80d8
The call to mergePairedInsns() deletes MI, so the later use by isUnscaledLdSt()
is referencing freed memory.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246033 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This change lowers the aarch64 integer vector min/max intrinsic nodes to
generic min/max nodes and replaces the intrinsic selection patterns with
the generic ones.
There should already be testing in place for this, so no further tests
were added.
Reviewers: jmolloy
Subscribers: aemerson, llvm-commits, rengolin
Differential Revision: http://reviews.llvm.org/D12276
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246030 91177308-0d34-0410-b5e6-96231b3b80d8
This was only added to preserve the old ScalarRepl's use of SSAUpdater
which was originally to avoid use of dominance frontiers. Now, we only
need a domtree, and we'll need a domtree right after this pass as well
and so it makes perfect sense to always and only use the dom-tree
powered mem2reg. This was flag-flipper earlier and has stuck reasonably
so I wanted to gut the now-dead code out of SROA before we waste more
time with it. Among other things, this will make passmanager porting
easier.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246028 91177308-0d34-0410-b5e6-96231b3b80d8
The binaries containing the linked DWARF generated by dsymutil are not
standard relocatable object files like emitted did previsously. They should be
dSYM companion files, which means they have a different file type in the
header, but also a couple other peculiarities:
- they contain the segments and sections from the original binary in their
load commands, but not the actual contents. This means they get an address
and a size, but their offset is always 0 (but these are not virtual sections)
- they also conatin all the defined symbols from the original binary
This makes MC a really bad fit to emit these kind of binaries. The approach
that was used in this patch is to leverage MC's section layout for the
debug sections, but to use a replacement for MachObjectWriter that lives
in MachOUtils.cpp. Some of the low-level helpers from MachObjectWriter
were reused too.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246012 91177308-0d34-0410-b5e6-96231b3b80d8
llvm-dsymutil needs to emit dSYM companion bundles. These are binary files
that replicate some of the orignal binary file properties (sections and
symbols). To get acces to these properties, pass the binary path in the
debug map.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246011 91177308-0d34-0410-b5e6-96231b3b80d8
Split a MCAssembler::layout() method out of MCAssembler::finish(). This allows
running the MCSections layout separately from the streaming of the output
file. This way if a client wants to use MC to generate section contents, but
emit something different than the standard relocatable object files it is
possible (llvm-dsymutil is such a client).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246008 91177308-0d34-0410-b5e6-96231b3b80d8
Hardcode less values in some mach-o header writing routines and pass them
as argument. Doing so will allow reusing this code in llvm-dsymutil.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246007 91177308-0d34-0410-b5e6-96231b3b80d8
This commit switches the underlying JIT for the Kaleidoscope tutorials from
MCJIT to a custom ORC-based JIT, KaleidoscopeJIT. This fixes a lot of the bugs
in Kaleidoscope that were introduced when we deleted the legacy JIT. The
documentation for Chapter 4, which introduces the JIT APIs, is updated to
reflect the change.
Also included are a number of C++11 modernizations and general cleanup. Where
appropriate, the docs have been updated to reflect these changes too.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246002 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: When comparing basic blocks, there is an additional check that two Value*'s should have the same ID, which interferes with merging equivalent constants of different kinds (such as a ConstantInt and a ConstantPointerNull in the included testcase). The cmpValues function already ensures that the two values in each function are the same, so removing this check should not cause incorrect merging.
Also, the type comparison is redundant, based on reviewing the code and testing on the test suite and several large LTO bitcodes.
Author: jrkoenig
Reviewers: nlewycky, jfb, dschuff
Subscribers: llvm-commits
Differential revision: http://reviews.llvm.org/D12302
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246001 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: Adds accessor functions for all the fields in llvm::fltSemantics. This will be used in MergeFunctions to order two APFloats with different semanatics.
Author: jrkoenig
Reviewers: jfb
Subscribers: dschuff, llvm-commits
Differential revision: http://reviews.llvm.org/D12253
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@245999 91177308-0d34-0410-b5e6-96231b3b80d8
This should be no functional change but for the record: For three cases
in X86FastISel this will change the order in which the FalseMBB and
TrueMBB of a conditional branch is addedd to the successor/predecessor
lists.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@245997 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This change makes the variable argument intrinsics, `llvm.va_start` and
`llvm.va_copy`, and the `va_arg` instruction behave as they do on Windows
inside a `CallingConv::X86_64_Win64` function. It's needed for a Clang patch
I have to add support for GCC's `__builtin_ms_va_list` constructs.
Reviewers: nadav, asl, eugenis
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1622
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@245990 91177308-0d34-0410-b5e6-96231b3b80d8
There was an issue in the test setup because the test requires an arch that
wasn't filtered by the lit.local.cfg, but given the set of bots that failed,
I'm not confident this is the (only) issue. So this commit also adds more
output to the test to help me track down the failure if it happens again.
Original commit message:
[dsymutil] Rewrite thumb triple names in user visible messages.
We autodetect triples from the input file(s) while reading the mach-o debug map.
As we need to create a Target from those triples, we always chose the thumb
variant (because the arm variant might not be 'instantiable' eg armv7m). The
user visible architecture names should still be 'arm' and not 'thumb' variants
though.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@245988 91177308-0d34-0410-b5e6-96231b3b80d8
Do the same for .weak (not implemented for now, but may as well to it). Update comment string to two semicolons.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@245982 91177308-0d34-0410-b5e6-96231b3b80d8
This is friendlier to the readers as it makes it clear that the API is
not meant for vregs but just for physregs.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@245977 91177308-0d34-0410-b5e6-96231b3b80d8
When lowering switch statement, if bit tests are used then LLVM will always generates a jump to the default statement in the last bit test. However, this is not necessary when all cases in bit tests cover a contiguous range. This is because when generating the bit tests header MBB, there is a range check that guarantees cases in bit tests won't go outside of [low, high], where low and high are minimum and maximum case values in the bit tests. This patch checks if this is the case and then doesn't emit jump to default statement and hence saves a bit test and a branch.
Differential Revision: http://reviews.llvm.org/D12249
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@245976 91177308-0d34-0410-b5e6-96231b3b80d8
This actually found one case when a test was matching instructions
from the output of a different test.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@245974 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r245960.
Multiple bots are failing on the new test. It seemd like llvm-dsymutil exits with an error. Investigating.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@245964 91177308-0d34-0410-b5e6-96231b3b80d8
We autodetect triples from the input file(s) while reading the mach-o debug map.
As we need to create a Target from those triples, we always chose the thumb
variant (because the arm variant might not be 'instantiable' eg armv7m). The
user visible architecture names should still be 'arm' and not 'thumb' variants
though.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@245960 91177308-0d34-0410-b5e6-96231b3b80d8