a Value* to a WeakVH was constructing a temporary WeakVH
(due to the implicit assignment operator). This avoids
that cost.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@83704 91177308-0d34-0410-b5e6-96231b3b80d8
is trivially rematerializable and integrate it into
TargetInstrInfo::isTriviallyReMaterializable. This way, all places that
need to know whether an instruction is rematerializable will get the
same answer.
This enables the useful parts of the aggressive-remat option by
default -- using AliasAnalysis to determine whether a memory location
is invariant, and removes the questionable parts -- rematting operations
with virtual register inputs that may not be live everywhere.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@83687 91177308-0d34-0410-b5e6-96231b3b80d8
While recording beginning of a function, use scope info from the first location entry instead of just relying on first location entry itself.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@83684 91177308-0d34-0410-b5e6-96231b3b80d8
mappings, which could cause errors and assert-failures. This patch fixes that,
adds a test, and refactors the global-mapping-removal code into a single place.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@83678 91177308-0d34-0410-b5e6-96231b3b80d8
constants used in inlining heuristics (especially
those used in more than one file). No functional change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@83675 91177308-0d34-0410-b5e6-96231b3b80d8
to declare that they preserve other passes without needing to pull in
additional header file or library dependencies. Convert MachineFunctionPass
and CodeGenLICM to make use of this.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@83555 91177308-0d34-0410-b5e6-96231b3b80d8
"LoopVR's logic was copied into ScalarEvolution::getUnsignedRange and
::getSignedRange. Please delete LoopVR."
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@83531 91177308-0d34-0410-b5e6-96231b3b80d8
implementations with a new MachineInstr::isInvariantLoad, which uses
MachineMemOperands and is target-independent. This brings MachineLICM
and other functionality to targets which previously lacked an
isInvariantLoad implementation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@83475 91177308-0d34-0410-b5e6-96231b3b80d8
a virtual register to eliminate a frame index, it can return that register
and the constant stored there to PEI to track. When scavenging to allocate
for those registers, PEI then tracks the last-used register and value, and
if it is still available and matches the value for the next index, reuses
the existing value rather and removes the re-materialization instructions.
Fancier tracking and adjustment of scavenger allocations to keep more
values live for longer is possible, but not yet implemented and would likely
be better done via a different, less special-purpose, approach to the
problem.
eliminateFrameIndex() is modified so the target implementations can return
the registers they wish to be tracked for reuse.
ARM Thumb1 implements and utilizes the new mechanism. All other targets are
simply modified to adjust for the changed eliminateFrameIndex() prototype.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@83467 91177308-0d34-0410-b5e6-96231b3b80d8
intuitive.
It does NOT update the value if the key is already in the map,
it also returns false if the key is already in the map, regardless
if the value matched.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@83458 91177308-0d34-0410-b5e6-96231b3b80d8
out of it, and jump threading, condprop and gvn are now getting
most of the benefit. This was approved by Nicholas and Nicolas.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@83390 91177308-0d34-0410-b5e6-96231b3b80d8
spill slot. When frame references are via the frame pointer, they will be
negative, but Thumb1 load/store instructions only allow positive immediate
offsets. Instead, Thumb1 will spill to R12.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@83336 91177308-0d34-0410-b5e6-96231b3b80d8
question, can we get rid of the BasicBlock versions of all inserters
and use Head == 0 to indicate the old case when GetInsertBlock == 0?
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@83216 91177308-0d34-0410-b5e6-96231b3b80d8
set, these flags indicate the instructions source / def operands have special
register allocation requirement that are not captured in their register classes.
Post-allocation passes (e.g. post-alloc scheduler) should not change their
allocations. e.g. ARM::LDRD require the two definitions to be allocated
even / odd register pair.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@83196 91177308-0d34-0410-b5e6-96231b3b80d8
Add a new TargetLoweringObjectFileMachO::getConstTextCoalSection method to
get access to that section.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@83178 91177308-0d34-0410-b5e6-96231b3b80d8
to emit target-specific things at the beginning of the asm output. This
fixes a problem for PPC, where the text sections are not being kept together
as expected. The base class doInitialization code calls DW->BeginModule()
which emits a bunch of DWARF section directives. The PPC doInitialization
code then emits all the TEXT section directives, with the intention that they
will be kept together. But as I understand it, the Darwin assembler treats
the default TEXT section as a special case and moves it to the beginning of
the file, which means that all those DWARF sections are in the middle of
the text. With this change, the EmitStartOfAsmFile hook is called before
the DWARF section directives are emitted, so that all the PPC text section
directives come out right at the beginning of the file.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@83176 91177308-0d34-0410-b5e6-96231b3b80d8
basic blocks that are so long that their size overflows a short.
Also assert that overflow does not happen in the future, as requested by Evan.
This fixes PR4401.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@83159 91177308-0d34-0410-b5e6-96231b3b80d8
information. This allows arbitrary code involving DW_OP_plus_uconst
and DW_OP_deref. The scheme allows for easy extention to include,
any, or all of the DW_OP_ opcodes. I thought about just exposing all
of them, but, wasn't sure if people wanted the dwarf opcodes exposed
in the api. Is that a layering violation?
With this scheme, the entire existing block scheme used by llvm-gcc
can be switched over to the new scheme. I think that would be
cleaner, as then the compiler specific bits are not present in llvm
proper. Before the old code can be yanked however, similar code in
clang would have to be removed.
Next up, more testing.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@83120 91177308-0d34-0410-b5e6-96231b3b80d8
unused DECLARE instruction.
KILL is not yet used anywhere, it will replace TargetInstrInfo::IMPLICIT_DEF
in the places where IMPLICIT_DEF is just used to alter liveness of physical
registers.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@83006 91177308-0d34-0410-b5e6-96231b3b80d8
the PassManager code into a regular verifyAnalysis method.
Also, reorganize loop verification. Make the LoopPass infrastructure
call verifyLoop as needed instead of having LoopInfo::verifyAnalysis
check every loop in the function after each looop pass. Add a new
command-line argument, -verify-loop-info, to enable the expensive
full checking.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@82952 91177308-0d34-0410-b5e6-96231b3b80d8
code that stops the timer doesn't have to search to find the timer
object before it stops the timer. This avoids a lock acquisition
and a few other things done with the timer running.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@82949 91177308-0d34-0410-b5e6-96231b3b80d8
setenv(). This patch just disables the test rather than getting putenv() to
work. Thanks to Sandeep Patel for reporting the problem.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@82797 91177308-0d34-0410-b5e6-96231b3b80d8
- Allocate MachineMemOperands and MachineMemOperand lists in MachineFunctions.
This eliminates MachineInstr's std::list member and allows the data to be
created by isel and live for the remainder of codegen, avoiding a lot of
copying and unnecessary translation. This also shrinks MemSDNode.
- Delete MemOperandSDNode. Introduce MachineSDNode which has dedicated
fields for MachineMemOperands.
- Change MemSDNode to have a MachineMemOperand member instead of its own
fields with the same information. This introduces some redundancy, but
it's more consistent with what MachineInstr will eventually want.
- Ignore alignment when searching for redundant loads for CSE, but remember
the greatest alignment.
Target-specific code which previously used MemOperandSDNodes with generic
SDNodes now use MemIntrinsicSDNodes, with opcodes in a designated range
so that the SelectionDAG framework knows that MachineMemOperand information
is available.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@82794 91177308-0d34-0410-b5e6-96231b3b80d8
naming scheme used in SelectionDAG, where there are multiple kinds
of "target" nodes, but "machine" nodes are nodes which represent
a MachineInstr.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@82790 91177308-0d34-0410-b5e6-96231b3b80d8
For the AAPCS ABI, SP must always be 4-byte aligned, and at any "public
interface" it must be 8-byte aligned. For the older ARM APCS ABI, the stack
alignment is just always 4 bytes. For X86, we currently align SP at
entry to a function (e.g., to 16 bytes for Darwin), but no stack alignment
is needed at other times, such as for a leaf function.
After discussing this with Dan, I decided to go with the approach of adding
a new "TransientStackAlignment" field to TargetFrameInfo. This value
specifies the stack alignment that must be maintained even in between calls.
It defaults to 1 except for ARM, where it is 4. (Some other targets may
also want to set this if they have similar stack requirements. It's not
currently required for PPC because it sets targetHandlesStackFrameRounding
and handles the alignment in target-specific code.) The existing StackAlignment
value specifies the alignment upon entry to a function, which is how we've
been using it anyway.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@82767 91177308-0d34-0410-b5e6-96231b3b80d8
this adjustment does not change the direction or the signs of the object
offsets, and the details of the offset calculations can be target-specific.
Also mention that for most targets this value is only used to generate debug
info.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@82750 91177308-0d34-0410-b5e6-96231b3b80d8
of the defs are processed.
Also fix a implicit_def propagation bug: a implicit_def of a physical register
should be applied to uses of the sub-registers.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@82616 91177308-0d34-0410-b5e6-96231b3b80d8
two different places for printing MachineMemOperands.
Drop the virtual from Value::dump and instead give Value a
protected virtual hook that can be overridden by subclasses
to implement custom printing. This lets printing be more
consistent, and simplifies printing of PseudoSourceValue
values.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@82599 91177308-0d34-0410-b5e6-96231b3b80d8
buffer", while we work out a solution.
Dan convinced me that making debugging annoying for him is worse than 10x being
slower for me. :)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@82553 91177308-0d34-0410-b5e6-96231b3b80d8
- This also fixes a dereference of std::string::end, which makes MSVC unhappy and was causing all the static analyzer clang tests to fail.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@82517 91177308-0d34-0410-b5e6-96231b3b80d8
This is designed for tracking a value even when it might move (like WeakVH), but it is an error to delete the referenced value (unlike WeakVH0. TrackingVH is templated like AssertingVH on the tracked Value subclass, it is an error to RAUW a tracked value to an incompatible type.
For implementation reasons the latter error is only diagnosed on accesses to a mis-RAUWed TrackingVH, because we don't want a virtual interface in a templated class.
The former error is also only diagnosed on access, so that clients are allowed to delete a tracked value, as long as they don't use it. This makes it easier for the client to reason about destruction.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@82506 91177308-0d34-0410-b5e6-96231b3b80d8
the base pointer, without the offset. This matches MemSDNode's
new alignment behavior, and holds more interesting information.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@82473 91177308-0d34-0410-b5e6-96231b3b80d8
is.
- The problem is that formatted_ostream forces its underlying buffer to be
unbuffered, so if some client happens to wrap a formatted_ostream around
something, but still use the underlying stream, then we can end up writing on
a fully unbuffered output (which was never intended to be unbuffered).
- This makes clang (and presumably llvm-gcc) -emit-llvm -S a mere 10x faster.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@82434 91177308-0d34-0410-b5e6-96231b3b80d8
feature, either build the JIT in debug mode to enable it by default or pass
-jit-emit-debug to lli.
Right now, the only debug information that this communicates to GDB is call
frame information, since it's already being generated to support exceptions in
the JIT. Eventually, when DWARF generation isn't tied so tightly to AsmPrinter,
it will be easy to push that information to GDB through this interface.
Here's a step-by-step breakdown of how the feature works:
- The JIT generates the machine code and DWARF call frame info
(.eh_frame/.debug_frame) for a function into memory.
- The JIT copies that info into an in-memory ELF file with a symbol for the
function.
- The JIT creates a code entry pointing to the ELF buffer and adds it to a
linked list hanging off of a global descriptor at a special symbol that GDB
knows about.
- The JIT calls a function marked noinline that GDB knows about and has put an
internal breakpoint in.
- GDB catches the breakpoint and reads the global descriptor to look for new
code.
- When sees there is new code, it reads the ELF from the inferior's memory and
adds it to itself as an object file.
- The JIT continues, and the next time we stop the program, we are able to
produce a proper backtrace.
Consider running the following program through the JIT:
#include <stdio.h>
void baz(short z) {
long w = z + 1;
printf("%d, %x\n", w, *((int*)NULL)); // SEGFAULT here
}
void bar(short y) {
int z = y + 1;
baz(z);
}
void foo(char x) {
short y = x + 1;
bar(y);
}
int main(int argc, char** argv) {
char x = 1;
foo(x);
}
Here is a backtrace before this patch:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x2aaaabdfbd10 (LWP 25476)]
0x00002aaaabe7d1a8 in ?? ()
(gdb) bt
#0 0x00002aaaabe7d1a8 in ?? ()
#1 0x0000000000000003 in ?? ()
#2 0x0000000000000004 in ?? ()
#3 0x00032aaaabe7cfd0 in ?? ()
#4 0x00002aaaabe7d12c in ?? ()
#5 0x00022aaa00000003 in ?? ()
#6 0x00002aaaabe7d0aa in ?? ()
#7 0x01000002abe7cff0 in ?? ()
#8 0x00002aaaabe7d02c in ?? ()
#9 0x0100000000000001 in ?? ()
#10 0x00000000014388e0 in ?? ()
#11 0x00007fff00000001 in ?? ()
#12 0x0000000000b870a2 in llvm::JIT::runFunction (this=0x1405b70,
F=0x14024e0, ArgValues=@0x7fffffffe050)
at /home/rnk/llvm-gdb/lib/ExecutionEngine/JIT/JIT.cpp:395
#13 0x0000000000baa4c5 in llvm::ExecutionEngine::runFunctionAsMain
(this=0x1405b70, Fn=0x14024e0, argv=@0x13f06f8, envp=0x7fffffffe3b0)
at /home/rnk/llvm-gdb/lib/ExecutionEngine/ExecutionEngine.cpp:377
#14 0x00000000007ebd52 in main (argc=2, argv=0x7fffffffe398,
envp=0x7fffffffe3b0) at /home/rnk/llvm-gdb/tools/lli/lli.cpp:208
And a backtrace after this patch:
Program received signal SIGSEGV, Segmentation fault.
0x00002aaaabe7d1a8 in baz ()
(gdb) bt
#0 0x00002aaaabe7d1a8 in baz ()
#1 0x00002aaaabe7d12c in bar ()
#2 0x00002aaaabe7d0aa in foo ()
#3 0x00002aaaabe7d02c in main ()
#4 0x0000000000b870a2 in llvm::JIT::runFunction (this=0x1405b70,
F=0x14024e0, ArgValues=...)
at /home/rnk/llvm-gdb/lib/ExecutionEngine/JIT/JIT.cpp:395
#5 0x0000000000baa4c5 in llvm::ExecutionEngine::runFunctionAsMain
(this=0x1405b70, Fn=0x14024e0, argv=..., envp=0x7fffffffe3c0)
at /home/rnk/llvm-gdb/lib/ExecutionEngine/ExecutionEngine.cpp:377
#6 0x00000000007ebd52 in main (argc=2, argv=0x7fffffffe3a8,
envp=0x7fffffffe3c0) at /home/rnk/llvm-gdb/tools/lli/lli.cpp:208
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@82418 91177308-0d34-0410-b5e6-96231b3b80d8
stringref because they may not be nul terminated. For options like -Lfoo
this now avoids a O(n) temporary std::strings where N is the length of
the string after -L.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@82345 91177308-0d34-0410-b5e6-96231b3b80d8
a massive number of temporary strings created when parsing a command line.
More still left to eliminate.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@82318 91177308-0d34-0410-b5e6-96231b3b80d8
to. This can be combined with LCSSA or SSI form to store more information on a
PHINode than can be computed by looking at its incoming values.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@82317 91177308-0d34-0410-b5e6-96231b3b80d8
this is run after the 'standard function passes', SRoA was
recently run. This saves a domfrontier construction. Thanks
to Eli for noticing this.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@82291 91177308-0d34-0410-b5e6-96231b3b80d8
