Okay, here's how to reproduce the problem:
1) Build a Release (or Release+Asserts) version of clang in the normal way.
2) Using the clang & clang++ binaries from (1), build a Release (or
Release+Asserts) version of the same sources, but this time enable LTO ---
specify the `-flto' flag on the command line.
3) Run the ARC migrator tests:
$ arcmt-test --args -triple x86_64-apple-darwin10 -fsyntax-only -x objective-c++ ./src/tools/clang/test/ARCMT/cxx-rewrite.mm
You'll see that the output isn't correct (the whitespace is off).
The mis-compile is in the function `RewriteBuffer::RemoveText' in the
clang/lib/Rewrite/Core/Rewriter.cpp file. When that function and RewriteRope.cpp
are compiled with LTO and the `arcmt-test' executable is regenerated, you'll see
the error. When those files are not LTO'ed, then the output of the `arcmt-test'
is fine.
It is *really* hard to get a testcase out of this. I'll file a PR with what I
have currently.
--- Reverse-merging r172363 into '.':
U include/llvm/Analysis/MemoryBuiltins.h
U lib/Analysis/MemoryBuiltins.cpp
--- Reverse-merging r171325 into '.':
U test/Transforms/InstCombine/objsize.ll
G include/llvm/Analysis/MemoryBuiltins.h
G lib/Analysis/MemoryBuiltins.cpp
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172756 91177308-0d34-0410-b5e6-96231b3b80d8
- This code is dead, and the "right" way to get this support is to use the
platform-specific linker-integrated LTO mechanisms, or the forthcoming LLVM
linker.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172749 91177308-0d34-0410-b5e6-96231b3b80d8
Move the early if-conversion pass into this group.
ILP optimizations usually need to find the right balance between
register pressure and ILP using the MachineTraceMetrics analysis to
identify critical paths and estimate other costs. Such passes should run
together so they can share dominator tree and loop info analyses.
Besides if-conversion, future passes to run here here could include
expression height reduction and ARM's MLxExpansion pass.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172687 91177308-0d34-0410-b5e6-96231b3b80d8
Moving the X86CostTable to a common place, so that other back-ends
can share the code. Also simplifying it a bit and commoning up
tables with one and two types on operations.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172658 91177308-0d34-0410-b5e6-96231b3b80d8
AT_producer. Which includes clang's version information so we can tell
which version of the compiler was used.
This is the first of two steps to allow us to do that. This is the llvm-mc
change to provide a method to set the AT_producer string. The second step,
coming soon to a clang near you, will have the clang driver pass the value
of getClangFullVersion() via an flag when invoking the integrated assembler
on assembly source files.
rdar://12955296
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172630 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
of a class. Emit static data member declarations and definitions
through correctly.
Part of PR14471.
Patch by Paul Robinson!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172590 91177308-0d34-0410-b5e6-96231b3b80d8
Since we already have this type it's a shame to keep dragging a pair of object
and method around explicitly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172584 91177308-0d34-0410-b5e6-96231b3b80d8
using the DW_FORM_GNU_addr_index and a separate .debug_addr section which
stays in the executable and is fully linked.
Sneak in two other small changes:
a) Print out the debug_str_offsets.dwo section.
b) Change form we're expecting the entries in the debug_str_offsets.dwo
section to take from ULEB128 to U32.
Add tests for all of this in the fission-cu.ll test.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172578 91177308-0d34-0410-b5e6-96231b3b80d8
into which we can emit single instructions without fixups (which is most
instructions). This is an optimization required because MCDataFragment
is prety large (240 bytes on x64), with no change in functionality.
For large programs, this reduces memory usage overhead required for bundling
by 40%.
To make the code as palatable as possible, the MCEncodedFragment interface was
further fragmented (no pun intended) and MCEncodedFragmentWithFixups is used
as the interface to work against when the user expects fixups. MCDataFragment
and MCRelaxableFragment implement this interface, while the new
MCCompactEncodedInstFragment implements MCEncodeFragment.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172572 91177308-0d34-0410-b5e6-96231b3b80d8
This simplifies the usage and implementation of ELFObjectFile by using ELFType
to replace:
<endianness target_endianness, std::size_t max_alignment, bool is64Bits>
This does complicate the base ELF types as they must now use template template
parameters to partially specialize for the 32 and 64bit cases. However these
are only defined once.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172515 91177308-0d34-0410-b5e6-96231b3b80d8
This finally allows AsmParser to no longer list GenericAsmParser as a friend.
All member vars directly accessed by GenericAsmParser have been properly
encapsulated and exposed through the MCAsmParser interface. This reduces the
coupling between AsmParser and GenericAsmParser.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172490 91177308-0d34-0410-b5e6-96231b3b80d8
Note that this bug is only exposed because LTO fails to use TTI.
Fixes self-LTO of clang. rdar://13007381.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172462 91177308-0d34-0410-b5e6-96231b3b80d8
Use the existing move implementation of the internal DenseMap::InsertIntoBucket
method to provide a user-facing move insert method.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172453 91177308-0d34-0410-b5e6-96231b3b80d8
Now that it behaves itself in terms of streamer independence (r172450), this
method can be moved to MCAsmParser to be available to all extensions,
overriding, etc.
-- -This line, and those below, will be ignored--
M lib/MC/MCParser/AsmParser.cpp
M include/llvm/MC/MCParser/MCAsmParser.h
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172451 91177308-0d34-0410-b5e6-96231b3b80d8
The aim of this patch is to fix the following piece of code in the
platform-independent AsmParser:
void AsmParser::CheckForValidSection() {
if (!ParsingInlineAsm && !getStreamer().getCurrentSection()) {
TokError("expected section directive before assembly directive");
Out.SwitchSection(Ctx.getMachOSection(
"__TEXT", "__text",
MCSectionMachO::S_ATTR_PURE_INSTRUCTIONS,
0, SectionKind::getText()));
}
}
This was added for the "-n" option of llvm-mc.
The proposed fix adds another virtual method to MCStreamer, called
InitToTextSection. Conceptually, it's similar to the existing
InitSections which initializes all common sections and switches to
text. The new method is implemented by each platform streamer in a way
that it sees fit. So AsmParser can now do this:
void AsmParser::CheckForValidSection() {
if (!ParsingInlineAsm && !getStreamer().getCurrentSection()) {
TokError("expected section directive before assembly directive");
Out.InitToTextSection();
}
}
Which is much more reasonable.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172450 91177308-0d34-0410-b5e6-96231b3b80d8
Since it's used by extensions. One further step to fully decoupling
GenericAsmParser from an intimate knowledge of the internals of AsmParser,
pointing it to the MCASmParser interface instead (like all other parser
extensions do).
Since this change moves the MacroArgument type to the interface header, it's
renamed to be a bit more descriptive in a general context.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172449 91177308-0d34-0410-b5e6-96231b3b80d8
The methods are also exposed via the MCAsmParser interface, which allows more
than one client to control them. Previously, GenericAsmParser was playing with
a member var in AsmParser directly (by virtue of being its friend).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172440 91177308-0d34-0410-b5e6-96231b3b80d8
Remember the minimum cost of the registers in an allocation order and
the number of registers at the end of the allocation order that have the
same cost per use.
This information can be used to limit the search space for
RAGreedy::tryEvict() when looking for a cheaper register.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172280 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes some of the cycles between libCodeGen and libSelectionDAG. It's still
a complete mess but as long as the edges consist of virtual call it doesn't
cause breakage. BasicTTI did static calls and thus broke some build
configurations.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172246 91177308-0d34-0410-b5e6-96231b3b80d8
