casted induction variables in cases where the cast
isn't foldable. It ended up being a pessimization in
many cases. This could be fixed, but it would require
a bunch of complicated code in IVUsers' clients. The
advantages of this approach aren't visible enough to
justify it at this time.
llvm-svn: 73706
- Register allocator should resolve the second part of the hint (register number) before passing it to the target since it knows virtual register to physical register mapping.
- More fixes to get ARM load / store double word working.
llvm-svn: 73671
adding a check to catch this case at compile time
instead of quietly generating incorrect code.
That will at least let us identify CBE failures
that are not due to this problem.
llvm-svn: 73668
move loads back past a check that the load address
is valid, see new testcase. The test that went
in with 72661 has exactly this case, except that
the conditional it's moving past is checking
something else; I've settled for changing that
test to reference a global, not a pointer. It
may be possible to scan all the tests you pass and
make sure none of them are checking any component
of the address, but it's not trivial and I'm not
trying to do that here.
llvm-svn: 73632
lock. This is obviously bad, but at least it's threadsafe! If you know how
to improve this in a pre-Vista friendly well, patches welcome!
Patch by Max Burke.
llvm-svn: 73607
>>
>
> It doesn't matter in terms of semantics: because AnalyzeGlobal
> returned false, we're guaranteed the address of the global is never
> taken. I wouldn't be surprised if we end up generating invalid IR in
> some cases, though, because of the semantics of replaceAllUsesWith.
> Do you have a testcase that breaks?
>
>
The problem is replaceAllUsesWith asserts for type mismatch here. Try attached .bc with llvm-ld.
assert(New->getType() == getType() &&
"replaceAllUses of value with new value of different type!");
Since stack is always on address space zero, I don't think that type of GV in a different address space is ever going to match.
The other way is to allow replaceAllUsesWith to ignore address spaces while comparing types. (do we have a way to do that ?).
But then such an optimization may fail the entire idea of user wanting to place a variable into different memory space. The original idea of user might be to save on the stack space (data memory) and hence he asked the variable to be placed into different memory space (program memory). So the best bet here is to deny this optimization by checking
GV->getType()->getAddressSpace() == 0.
llvm-svn: 73605
object files. Now we always build LLVM libraries into archives (.a files).
This makes the 'make' build work more like the cmake build, among other
things. Doing this exposed some latent circular library dependencies, so
I think that llvm-config wasn't quite right for .o files anyway.
llvm-svn: 73579
initialization of all targets (InitializeAllTargets.h) or assembler
printers (InitializeAllAsmPrinters.h). This is a step toward the
elimination of relinked object files, so that we can build normal
archives.
llvm-svn: 73543
obscuring what would otherwise be a low-bits mask. Use ComputeMaskedBits
to compute what ShrinkDemandedConstant knew about to reconstruct a
low-bits mask value.
llvm-svn: 73540
TurnCopyIntoImpDef turns a copy into implicit_def and remove the val# defined by it. This causes an scavenger assertion later if the def reaches other blocks. Disable the transformation if the value live interval extends beyond its def block.
llvm-svn: 73478
support for x86, and UMULO/SMULO for many architectures, including PPC
(PR4201), ARM, and Cell. The resulting expansion isn't perfect, but it's
not bad.
llvm-svn: 73477
The problem was that BitcodeReader::materializeModule would read functions
from the bc file in densemap pointer key order (doubly non-deterministic!),
which would cause the use-def chains to be set up for globals in
non-determinstic order. Non-determinstic use/def chains can cause
nondeterminism in many places down-stream.
Many thanks to Julien Lerouge for putting together the pass in the PR that
shows the issue!
llvm-svn: 73470
comes after the DW_CFA_def_cfa_register, because the CFA is really ESP from the
start of the function and only gets an offset when the "subl $xxx,%esp"
instruction happens, not the other way around.
And reapply r72898:
The DWARF unwind info was incorrect. While compiling with
`-fomit-frame-pointer', we would lack the DW_CFA_advance_loc information for a
lot of function, and then they would be `0'. The linker (at least on Darwin)
needs to encode the stack size. In some cases, the stack size is too large to
directly encode. So the linker checks to see if there is a "subl $xxx,%esp"
instruction at the point where the `DW_CFA_def_cfa_offset' says the pc was. If
so, the compact encoding records the offset in the function to where the stack
size is embedded. But because the `DW_CFA_advance_loc' instructions are missing,
it looks before the function and dies.
So, instead of emitting the EH debug label before the stack adjustment
operations, emit it afterwards, right before the frame move stuff.
llvm-svn: 73465
failures.
To support this, add some utility functions to Type to help support
vector/scalar-independent code. Change ConstantInt::get and
ConstantFP::get to support vector types, and add an overload to
ConstantInt::get that uses a static IntegerType type, for
convenience.
Introduce a new getConstant method for ScalarEvolution, to simplify
common use cases.
llvm-svn: 73431
that push immediate operands of 1, 2, and 4 bytes (extended to the native
register size in each case). The assembly mnemonics are "pushl" and "pushq."
One such instruction appears at the beginning of the "start" function , so this
is essential for accurate disassembly when unwinding."
Patch by Sean Callanan!
llvm-svn: 73407
specific one. The GNU one is chosen when _GNU_SOURCE is defined. g++ always
defines _GNU_SOURCE on linux platforms because glibc's headers won't compile
in C++ mode without it. The GNU strerror_r doesn't always modify the buffer
which causes empty error messages on linux.
This patch changes MakeErrMsg to use the return value of strerror_r to get
the string instead of assuming the buffer will be modified, on GLIBC.
Patch by Benjamin Kramer!
llvm-svn: 73396
incomming chain of the RETURN node. The incomming chain must
be the outgoing chain of the CALL node. This causes the
backend to identify tail calls that are not tail calls. This
patch fixes this.
llvm-svn: 73387
Look for as in the path. Doing it here instead
of llvm-gcc because llvm-gcc has nothing as
convenient as sys::Program::FindProgramByName.
llvm-svn: 73383
- Change register allocation hint to a pair of unsigned integers. The hint type is zero (which means prefer the register specified as second part of the pair) or entirely target dependent.
- Allow targets to specify alternative register allocation orders based on allocation hint.
Part 2.
- Use the register allocation hint system to implement more aggressive load / store multiple formation.
- Aggressively form LDRD / STRD. These are formed *before* register allocation. It has to be done this way to shorten live interval of base and offset registers. e.g.
v1025 = LDR v1024, 0
v1026 = LDR v1024, 0
=>
v1025,v1026 = LDRD v1024, 0
If this transformation isn't done before allocation, v1024 will overlap v1025 which means it more difficult to allocate a register pair.
- Even with the register allocation hint, it may not be possible to get the desired allocation. In that case, the post-allocation load / store multiple pass must fix the ldrd / strd instructions. They can either become ldm / stm instructions or back to a pair of ldr / str instructions.
This is work in progress, not yet enabled.
llvm-svn: 73381
Ted Kremenek