| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D7430
llvm-svn: 228487
|
| |
|
|
| |
llvm-svn: 227949
|
| |
|
|
| |
llvm-svn: 227841
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
described by integer constants. This is a bit ugly, but if the source
language allows arbitrary type casting, the debug info must follow suit.
For example:
void foo() {
float a;
*(int *)&a = 0;
}
For the curious: SROA replaces the float alloca with an i32 alloca, which
is then optimized away and described via dbg.value(i32 0, ...).
llvm-svn: 227827
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Any code creating an MCSectionELF knows ELF and already provides the flags.
SectionKind is an abstraction used by common code that uses a plain
MCSection.
Use the flags to compute the SectionKind. This removes a lot of
guessing and boilerplate from the MCSectionELF construction.
llvm-svn: 227476
|
| |
|
|
| |
llvm-svn: 227291
|
| |
|
|
|
|
| |
member is a typedef (or other sugar) of a declaration.
llvm-svn: 227290
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
derived classes.
Since global data alignment, layout, and mangling is often based on the
DataLayout, move it to the TargetMachine. This ensures that global
data is going to be layed out and mangled consistently if the subtarget
changes on a per function basis. Prior to this all targets(*) have
had subtarget dependent code moved out and onto the TargetMachine.
*One target hasn't been migrated as part of this change: R600. The
R600 port has, as a subtarget feature, the size of pointers and
this affects global data layout. I've currently hacked in a FIXME
to enable progress, but the port needs to be updated to either pass
the 64-bitness to the TargetMachine, or fix the DataLayout to
avoid subtarget dependent features.
llvm-svn: 227113
|
| |
|
|
|
|
|
|
|
|
|
| |
physical register that is described in a DBG_VALUE.
In the testcase the DBG_VALUE describing "p5" becomes unavailable
because the register its address is in is clobbered and we (currently)
aren't smart enough to realize that the value is rematerialized immediately
after the DBG_VALUE and/or is actually a stack slot.
llvm-svn: 227056
|
| |
|
|
|
|
| |
Minor tweaks to whitespace formatting that I noticed was off. NFC.
llvm-svn: 227014
|
| |
|
|
|
|
| |
Should fix PR22305.
llvm-svn: 226969
|
| |
|
|
|
|
|
|
| |
- input_iterator
- define an operator->
- make constructors private were possible
llvm-svn: 226967
|
| |
|
|
|
|
|
|
| |
DIExpression::Operand, so we can write range-based for loops.
Thanks to David Blaikie for the idea.
llvm-svn: 226939
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This mostly reverts commit r222062 and replaces it with a new enum. At
some point this enum will grow at least for other MSVC EH personalities.
Also beefs up the way we were sniffing the personality function.
Previously we would emit the Itanium LSDA despite using
__C_specific_handler.
Reviewers: majnemer
Differential Revision: http://reviews.llvm.org/D6987
llvm-svn: 226920
|
| |
|
|
| |
llvm-svn: 226919
|
| |
|
|
|
|
|
|
|
|
|
| |
problems when inlining two calls to the same function from the same call site."
The underlying bug has been fixed in r226736 so there's no need to
workaround this anymore.
This reverts commit r220923.
llvm-svn: 226842
|
| |
|
|
|
|
| |
Addresses review feedback from Duncan.
llvm-svn: 226835
|
| |
|
|
| |
llvm-svn: 226767
|
| |
|
|
| |
llvm-svn: 226748
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
frontends to use a DIExpression with a DW_OP_deref instead.
This is not only a much more natural place for this informationl; there
is also a technical reason: The FlagIndirectVariable is used to mark a
variable that is turned into a reference by virtue of the calling
convention; this happens for example to aggregate return values.
The inliner, for example, may actually need to undo this indirection to
correctly represent the value in its new context. This is impossible to
implement because the DIVariable can't be safely modified. We can however
safely construct a new DIExpression on the fly.
llvm-svn: 226476
|
| |
|
|
| |
llvm-svn: 226414
|
| |
|
|
|
|
| |
Nothing interesting here...
llvm-svn: 226342
|
| |
|
|
| |
llvm-svn: 226077
|
| |
|
|
|
|
|
|
|
| |
MMI->getPersonalities()[MMI->getPersonalityIndex()]
Also nuke the comment about supporting multiple personalities in a
single function, aka PR1414. That's just crazy.
llvm-svn: 226052
|
| |
|
|
|
|
|
|
|
|
| |
This fixes lots of generic CodeGen tests that use __gcc_personality_v0.
This suggests that using ExceptionHandling::MSVC was a mistake, and we
should instead classify each function by personality function. This
would, for example, allow us to LTO a binary containing uses of SEH and
Itanium EH.
llvm-svn: 226019
|
| |
|
|
|
|
|
|
|
|
|
| |
utils/sort_includes.py.
I clearly haven't done this in a while, so more changed than usual. This
even uncovered a missing include from the InstrProf library that I've
added. No functionality changed here, just mechanical cleanup of the
include order.
llvm-svn: 225974
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds handling for ExceptionHandling::MSVC, used by the
x86_64-pc-windows-msvc triple. It assumes that filter functions have
already been outlined in either the frontend or the backend. Filter
functions are used in place of the landingpad catch clause type info
operands. In catch clause order, the first filter to return true will
catch the exception.
The C specific handler table expects the landing pad to be split into
one block per handler, but LLVM IR uses a single landing pad for all
possible unwind actions. This patch papers over the mismatch by
synthesizing single instruction BBs for every catch clause to fill in
the EH selector that the landing pad block expects.
Missing functionality:
- Accessing data in the parent frame from outlined filters
- Cleanups (from __finally) are unsupported, as they will require
outlining and parent frame access
- Filter clauses are unsupported, as there's no clear analogue in SEH
In other words, this is the minimal set of changes needed to write IR to
catch arbitrary exceptions and resume normal execution.
Reviewers: majnemer
Differential Revision: http://reviews.llvm.org/D6300
llvm-svn: 225904
|
| |
|
|
|
|
|
|
| |
DIEDwarfExpression (and get rid of a bunch of redundant code).
NFC
llvm-svn: 225900
|
| |
|
|
|
|
|
|
| |
status in a bool and let the users deal with the error.
NFC.
llvm-svn: 225899
|
| |
|
|
|
|
|
|
| |
needs to be accessed from both DwarfCompileUnit.cpp and DwarfUnit.cpp.
NFC.
llvm-svn: 225898
|
| |
|
|
|
|
| |
no frame register. "Tested" via an assertion triggered by DwarfExpression.
llvm-svn: 225858
|
| |
|
|
|
|
|
|
|
| |
This reverts commit r225852, it was a bad idea.
MachineReg should always be a physical register. If it isn't this DebugLoc
shouldn't have been created in the first place.
llvm-svn: 225857
|
| |
|
|
|
|
|
| |
physical register. The call to getMinimalPhysRegClass() later on asserts
on this condition.
llvm-svn: 225852
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
emitDebugLocValue() into DwarfExpression.
Ought to be NFC, but it actually uncovered a bug in the debug-loc-asan.ll
testcase. The testcase checks that the address of variable "y" is stored
at [RSP+16], which also lines up with the comment.
It also check(ed) that the *value* of "y" is stored in RDI before that,
but that is actually incorrect, since RDI is the very value that is
stored in [RSP+16]. Here's the assembler output:
movb 2147450880(%rcx), %r8b
#DEBUG_VALUE: bar:y <- RDI
cmpb $0, %r8b
movq %rax, 32(%rsp) # 8-byte Spill
movq %rsi, 24(%rsp) # 8-byte Spill
movq %rdi, 16(%rsp) # 8-byte Spill
.Ltmp3:
#DEBUG_VALUE: bar:y <- [RSP+16]
Fixed the comment to spell out the correct register and the check to
expect an address rather than a value.
Note that the range that is emitted for the RDI location was and is still
wrong, it claims to begin at the function prologue, but really it should
start where RDI is first assigned.
llvm-svn: 225851
|
| |
|
|
| |
llvm-svn: 225848
|
| |
|
|
| |
llvm-svn: 225847
|
| |
|
|
|
|
|
|
| |
function.
NFC.
llvm-svn: 225846
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These intrinsics allow multiple functions to share a single stack
allocation from one function's call frame. The function with the
allocation may only perform one allocation, and it must be in the entry
block.
Functions accessing the allocation call llvm.recoverframeallocation with
the function whose frame they are accessing and a frame pointer from an
active call frame of that function.
These intrinsics are very difficult to inline correctly, so the
intention is that they be introduced rarely, or at least very late
during EH preparation.
Reviewers: echristo, andrew.w.kaylor
Differential Revision: http://reviews.llvm.org/D6493
llvm-svn: 225746
|
| |
|
|
|
|
|
|
|
| |
Move the declaration of DebugLocDwarfExpression into DwarfExpression.h
because it needs to be accessed from AsmPrinterDwarf.cpp and DwarfDebug.cpp
NFC.
llvm-svn: 225734
|
| |
|
|
|
|
| |
NFC.
llvm-svn: 225731
|
| |
|
|
| |
llvm-svn: 225730
|
| |
|
|
|
|
| |
readability.
llvm-svn: 225726
|
| |
|
|
|
|
| |
Thanks Chandler for noticing!
llvm-svn: 225724
|
| |
|
|
| |
llvm-svn: 225720
|
| |
|
|
|
|
| |
NFC.
llvm-svn: 225717
|
| |
|
|
|
|
| |
No functional change.
llvm-svn: 225707
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
into a new class DwarfExpression that can be shared between AsmPrinter
and DwarfUnit.
This is the first step towards unifying the two entirely redundant
implementations of dwarf expression emission in DwarfUnit and AsmPrinter.
Almost no functional change — Testcases were updated because asm comments
that used to be on two lines now appear on the same line, which is
actually preferable.
llvm-svn: 225706
|
| |
|
|
| |
llvm-svn: 225399
|
| |
|
|
| |
llvm-svn: 225378
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change includes the most basic possible GCStrategy for a GC which is using the statepoint lowering code. At the moment, this GCStrategy doesn't really do much - aside from actually generate correct stackmaps that is - but I went ahead and added a few extra correctness checks as proof of concept. It's mostly here to provide documentation on how to do one, and to provide a point for various optimization legality hooks I'd like to add going forward. (For context, see the TODOs in InstCombine around gc.relocate.)
Most of the validation logic added here as proof of concept will soon move in to the Verifier. That move is dependent on http://reviews.llvm.org/D6811
There was discussion in the review thread about addrspace(1) being reserved for something. I'm going to follow up on a seperate llvmdev thread. If needed, I'll update all the code at once.
Note that I am deliberately not making a GCStrategy required to use gc.statepoints with this change. I want to give folks out of tree - including myself - a chance to migrate. In a week or two, I'll make having a GCStrategy be required for gc.statepoints. To this end, I added the gc tag to one of the test cases but not others.
Differential Revision: http://reviews.llvm.org/D6808
llvm-svn: 225365
|