this clang will use .debug_frame in, for example,
clang -g -c -m32 test.c
This matches gcc's behaviour. It looks like .debug_frame is a bit bigger
than .eh_frame, but has the big advantage of not being allocated.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@131140 91177308-0d34-0410-b5e6-96231b3b80d8
DWARF stuff also gets fixed up by ELFARMAsmBackend::ApplyFixup(),
but the offset is not guaranteed to be mod 4 == 0 as in text/data.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@131137 91177308-0d34-0410-b5e6-96231b3b80d8
The previous invalidation missed the alias interference caches.
Also add a stats counter for the number of repaired ranges.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@131133 91177308-0d34-0410-b5e6-96231b3b80d8
It can happen that a live debug variable is the last use of a sub-register, and
the register allocator will pick a larger register class for the virtual
register. If the allocated register doesn't support the sub-register index,
just use %noreg for the debug variables instead of asserting.
In PR9872, a debug variable ends up in the sub_8bit_hi part of a GR32_ABCD
register. The register is split and one part is inflated to GR32 and assigned
%ESI because there are no more normal uses of sub_8bit_hi.
Since %ESI doesn't have that sub-register, substPhysReg asserted. Now it will
simply insert a %noreg instead, and the debug variable will be marked
unavailable in that range.
We don't currently have a way of saying: !"value" is in bits 8-15 of %ESI, I
don't know if DWARF even supports that.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@131073 91177308-0d34-0410-b5e6-96231b3b80d8
the smaller encoding and this cuts 270336 bytes from a release version of
clang and 1246272 bytes from a debug build.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@131067 91177308-0d34-0410-b5e6-96231b3b80d8
The RegisterInfo.td file should only specify the indexes that sources need to
refer to. The rest is inferred.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@131058 91177308-0d34-0410-b5e6-96231b3b80d8
often expressed as "x >= y ? x : y", there is a good chance we can extract
the existing "x >= y" from it and use that as a replacement for "max(x,y)==x".
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@131049 91177308-0d34-0410-b5e6-96231b3b80d8
As an ExecutionEngine class function, its definition
really belongs in ExecutionEngine.cpp, not JIT.cpp.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@131027 91177308-0d34-0410-b5e6-96231b3b80d8
In particular, into EngineBuilder. This should only impact
the private API between the EE and EB classes, not external
clients, since JITCtor and MCJITCtor are both protected members.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@131026 91177308-0d34-0410-b5e6-96231b3b80d8
This prepares for making JITCtor/MCJITCtor take a
TargetMachine* directly from clients like EngineBuilder.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@131025 91177308-0d34-0410-b5e6-96231b3b80d8
This can't be just an assertion, users can always write impossible inline
assembly. Such an assembly statement should be included in the error message.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@131024 91177308-0d34-0410-b5e6-96231b3b80d8
assert in the bitcode writer. No change needed because the ValueEnumerator holds
a whole-module numbering anyhow. Fixes PR9857!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@131016 91177308-0d34-0410-b5e6-96231b3b80d8
