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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@73632 91177308-0d34-0410-b5e6-96231b3b80d8
Document those ValueMap functions that are _not_ locked, so that callers are aware that they need to do the locking themselves.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@73628 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@73607 91177308-0d34-0410-b5e6-96231b3b80d8
>>
>
> 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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@73605 91177308-0d34-0410-b5e6-96231b3b80d8
that gets recognized with a SCEVZeroExtendExpr must be an And
with a low-bits mask. With r73540, this is no longer the case.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@73594 91177308-0d34-0410-b5e6-96231b3b80d8
There's still some more work to be done here, such as guarding removeAbstractTypeUser() and the printers.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@73575 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@73543 91177308-0d34-0410-b5e6-96231b3b80d8
obscuring what would otherwise be a low-bits mask. Use ComputeMaskedBits
to compute what ShrinkDemandedConstant knew about to reconstruct a
low-bits mask value.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@73540 91177308-0d34-0410-b5e6-96231b3b80d8
(this is the case when we have thumb vararg function with single
callee-saved register, which is handled separately).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@73529 91177308-0d34-0410-b5e6-96231b3b80d8
to ignore readonly calls, and factor it out of instcombine so
that it can be used by other passes. Patch by Frits van Bommel!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@73506 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@73478 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@73477 91177308-0d34-0410-b5e6-96231b3b80d8
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!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@73470 91177308-0d34-0410-b5e6-96231b3b80d8
