| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
| |
horrible/fragile.
rdar://problem/16264854
llvm-svn: 203309
|
|
|
|
| |
llvm-svn: 203307
|
|
|
|
| |
llvm-svn: 203305
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
First: refactor out the emission of entries into the .debug_loc section
into its own routine.
Second: add a new class ByteStreamer that can be used to either emit
using an AsmPrinter or hash using DIEHash the series of bytes that
would be emitted. Use this in all of the location emission routines
for the .debug_loc section.
No functional change intended outside of a few additional comments
in verbose assembly.
llvm-svn: 203304
|
|
|
|
|
|
| |
to the hash.
llvm-svn: 203303
|
|
|
|
|
|
| |
This breaks linux buildbots. Go figure.
llvm-svn: 203300
|
|
|
|
| |
llvm-svn: 203297
|
|
|
|
|
|
| |
Suggested by Adrian Prantl in code review for r203187.
llvm-svn: 203296
|
|
|
|
|
|
| |
No functionality change.
llvm-svn: 203288
|
|
|
|
| |
llvm-svn: 203286
|
|
|
|
|
|
| |
No functionality change.
llvm-svn: 203276
|
|
|
|
|
|
| |
It has a lot of them with complex types. C++11 really shines here.
llvm-svn: 203270
|
|
|
|
|
|
|
| |
For incoming improvements to inlined functions and lexical blocks
suggested by Adrian Prantl in review of r203187.
llvm-svn: 203263
|
|
|
|
|
|
|
|
| |
spec
Code review feedback to r203187 from Oliver Stannard. Thanks!
llvm-svn: 203256
|
|
|
|
|
|
|
|
|
| |
This helps the instruction selector to lower an i64 * i64 -> i128
multiplication into a single instruction on targets which support it.
Patch by Manuel Jacob.
llvm-svn: 203230
|
|
|
|
| |
llvm-svn: 203221
|
|
|
|
|
|
| |
class.
llvm-svn: 203220
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
llvm/MC/MCSectionMachO.h and llvm/Support/MachO.h both had the same
definitions for the section flags. Instead, grab the definitions out of
support.
No functionality change.
Reviewers: grosbach, Bigcheese, rafael
Reviewed By: rafael
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D2998
llvm-svn: 203211
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The old system was fairly convoluted:
* A temporary label was created.
* A single PROLOG_LABEL was created with it.
* A few MCCFIInstructions were created with the same label.
The semantics were that the cfi instructions were mapped to the PROLOG_LABEL
via the temporary label. The output position was that of the PROLOG_LABEL.
The temporary label itself was used only for doing the mapping.
The new CFI_INSTRUCTION has a 1:1 mapping to MCCFIInstructions and points to
one by holding an index into the CFI instructions of this function.
I did consider removing MMI.getFrameInstructions completelly and having
CFI_INSTRUCTION own a MCCFIInstruction, but MCCFIInstructions have non
trivial constructors and destructors and are somewhat big, so the this setup
is probably better.
The net result is that we don't create temporary labels that are never used.
llvm-svn: 203204
|
|
|
|
| |
llvm-svn: 203192
|
|
|
|
| |
llvm-svn: 203191
|
|
|
|
| |
llvm-svn: 203190
|
|
|
|
|
|
|
| |
This removes a relocation from each subprogram, reducing link times,
etc.
llvm-svn: 203187
|
|
|
|
|
|
| |
Clang now uses llvm.compiler.used for these cases.
llvm-svn: 203174
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch teaches the DAGCombiner how to fold a binary OR between two
shufflevector into a single shuffle vector when possible.
The rules are:
1. fold (or (shuf A, V_0, MA), (shuf B, V_0, MB)) -> (shuf A, B, Mask1)
2. fold (or (shuf A, V_0, MA), (shuf B, V_0, MB)) -> (shuf B, A, Mask2)
The DAGCombiner can take advantage of the fact that OR is commutative and
compute two possible shuffle masks (Mask1 and Mask2) for the resulting
shuffle node.
Before folding a dag according to either rule 1 or 2, DAGCombiner verifies
that the resulting shuffle mask is legal for the target.
DAGCombiner would firstly try to fold according to 1.; If not possible
then it will try to fold according to 2.
If both Mask1 and Mask2 are illegal then we conservatively don't fold
the OR instruction.
llvm-svn: 203156
|
|
|
|
| |
llvm-svn: 203150
|
|
|
|
|
|
| |
No functional change.
llvm-svn: 203142
|
|
|
|
|
|
|
| |
This appears to only be working for global loads. Private
and local break for other reasons.
llvm-svn: 203135
|
|
|
|
| |
llvm-svn: 203127
|
|
|
|
|
|
|
|
|
|
| |
This compiles with no changes to clang/lld/lldb with MSVC and includes
overloads to various functions which are used by those projects and llvm
which have OwningPtr's as parameters. This should allow out of tree
projects some time to move. There are also no changes to libs/Target,
which should help out of tree targets have time to move, if necessary.
llvm-svn: 203083
|
|
|
|
|
|
|
|
|
|
| |
DW_AT_GNU_pubnames of DW_FORM_flag(_present) rather than sec_offsets to the pubnames/types sections
This is consistent with GDB ToT and reduces the number of relocations in
(type and compile) units, substantially reducing relocations and debug
size in fission + type units builds.
llvm-svn: 203082
|
|
|
|
|
|
| |
emitting pub sections for compile units
llvm-svn: 203057
|
|
|
|
| |
llvm-svn: 203055
|
|
|
|
|
|
| |
already lives.
llvm-svn: 203046
|
|
|
|
|
|
|
|
| |
pointed to by the attribute, rather than the form as a first
step to determining how to hash the values. No functional change
intended.
llvm-svn: 203044
|
|
|
|
|
|
| |
already lives.
llvm-svn: 203038
|
|
|
|
|
|
|
|
| |
This works by moving the existing code into the DIEValue hierarchy
and using the DwarfDebug pointer off of the AsmPrinter to access
any global information we need.
llvm-svn: 203033
|
|
|
|
| |
llvm-svn: 203032
|
|
|
|
|
|
| |
for verbose asm.
llvm-svn: 203031
|
|
|
|
|
|
|
|
| |
This enables us to figure out where in the debug_loc section our
locations are so that we can eventually hash them. It also helps
remove some special case code in emission. No functional change.
llvm-svn: 203018
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before llvm-mc would print it, but llc was assuming that it would produce
another section changing directive before one was needed. That assumption is
false with inline asm.
Fixes PR19049.
Another option would be to always create the section, but in the asm printer
avoid printing sections changes during initialization. That would work, but
* We do use the fact that llvm-mc prints it in testing. The tests can be changed
if needed.
* A quick poll on IRC suggest that most developers prefer the implicit .text to
be printed.
llvm-svn: 203001
|
|
|
|
|
|
|
|
|
|
|
| |
already lived there and it is where it belongs -- this is the in-memory
debug location representation.
This is just cleanup -- Modules can actually cope with this, but that
doesn't make it right. After chatting with folks that have out-of-tree
stuff, going ahead and moving the rest of the headers seems preferable.
llvm-svn: 202960
|
|
|
|
| |
llvm-svn: 202957
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Patchpoints already did this. Doing it for stackmaps is a convenience
for the runtime in the event that it needs to scratch register to
patch or perform a runtime call thunk.
Unlike patchpoints, we just assume the AnyRegCC calling
convention. This is the only language and target independent calling
convention specific to stackmaps so makes sense. Although the calling
convention is not currently used to select the scratch registers.
llvm-svn: 202943
|
|
|
|
| |
llvm-svn: 202932
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
selection dag (PR19012)
In X86SelectionDagInfo::EmitTargetCodeForMemcpy we check with MachineFrameInfo
to make sure that ESI isn't used as a base pointer register before we choose to
emit rep movs (which clobbers esi).
The problem is that MachineFrameInfo wouldn't know about dynamic allocas or
inline asm that clobbers the stack pointer until SelectionDAGBuilder has
encountered them.
This patch fixes the problem by checking for such things when building the
FunctionLoweringInfo.
Differential Revision: http://llvm-reviews.chandlerc.com/D2954
llvm-svn: 202930
|
|
|
|
| |
llvm-svn: 202926
|
|
|
|
|
|
|
| |
using a full uint16_t with the flag value... which happens to be
0 or 1. Update the class for bool values and rename functions slightly.
llvm-svn: 202921
|
|
|
|
| |
llvm-svn: 202920
|
|
|
|
| |
llvm-svn: 202919
|