-filetype=obj test, and -filetype=obj leaks a few objects. Added a FIXME, we
need to sort out the ownership model for the various MC objects.
llvm-svn: 103769
be diced into atoms, and adjust getAtom() to take this into account.
- This fixes relocations to symbols in fixed size literal sections, for
example.
llvm-svn: 103532
Sorry for the big change. The path leading up to this patch had some TableGen
changes that I didn't want to commit before I knew they were useful. They
weren't, and this version does not need them.
The fast register allocator now does no liveness calculations. Instead it relies
on kill flags provided by isel. (Currently those kill flags are also ignored due
to isel bugs). The allocation algorithm is supposed to work with any subset of
valid kill flags. More kill flags simply means fewer spills inserted.
Registers are allocated from a working set that contains no aliases. That means
most allocations can be done directly without expensive alias checks. When the
working set runs out of registers we do the full alias check to find new free
registers.
llvm-svn: 103488
- This eliminates getAtomForAddress() (which was a linear search) and
simplifies getAtom().
- This also fixes some correctness problems where local labels at the same
address as non-local labels could be assigned to the wrong atom.
llvm-svn: 103480
This includes a patch by Roman Divacky to fix the initial crash.
Move the actual addition of passes from *PassManager::add to
*PassManager::addImpl. That way, when adding printer passes we won't
recurse infinitely.
Finally, check to make sure that we are actually adding a FunctionPass
to a FunctionPassManager before doing a print before or after it.
Immutable passes are strange in this way because they aren't
FunctionPasses yet they can be and are added to the FunctionPassManager.
llvm-svn: 103425
when it detects undefined behavior. llvm.trap generally codegens into some
thing really small (e.g. a 2 byte ud2 instruction on x86) and debugging this
sort of thing is "nontrivial". For example, we now compile:
void foo() { *(int*)0 = 42; }
into:
_foo:
pushl %ebp
movl %esp, %ebp
ud2
Some may even claim that this is a security hole, though that seems dubious
to me. This addresses rdar://7958343 - Optimizing away null dereference
potentially allows arbitrary code execution
llvm-svn: 103356
with a vector input and output into a shuffle vector. This sort of
sequence happens when the input code stores with one type and reloads
with another type and then SROA promotes to i96 integers, which make
everyone sad.
This fixes rdar://7896024
llvm-svn: 103354
LSRUse's Regs set after all pruning is done, rather than trying
to do it on the fly, which can produce an incomplete result.
This fixes a case where heuristic pruning was stripping all
formulae from a use, which led the solver to enter an infinite
loop.
Also, add a few asserts to diagnose this kind of situation.
llvm-svn: 103328
getConstantFP to accept the two supported long double
target types. This was not the original intent, but
there are other places that assume this works and it's
easy enough to do.
llvm-svn: 103299
