Commit Graph

17 Commits

Author SHA1 Message Date
David Blaikie
7c9c6ed761 [opaque pointer type] Add textual IR support for explicit type parameter to load instruction
Essentially the same as the GEP change in r230786.

A similar migration script can be used to update test cases, though a few more
test case improvements/changes were required this time around: (r229269-r229278)

import fileinput
import sys
import re

pat = re.compile(r"((?:=|:|^)\s*load (?:atomic )?(?:volatile )?(.*?))(| addrspace\(\d+\) *)\*($| *(?:%|@|null|undef|blockaddress|getelementptr|addrspacecast|bitcast|inttoptr|\[\[[a-zA-Z]|\{\{).*$)")

for line in sys.stdin:
  sys.stdout.write(re.sub(pat, r"\1, \2\3*\4", line))

Reviewers: rafael, dexonsmith, grosser

Differential Revision: http://reviews.llvm.org/D7649

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230794 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-27 21:17:42 +00:00
Shuxin Yang
6c7a7c6474 Fix PR17952.
The symptom is that an assertion is triggered. The assertion was added by
me to detect the situation when value is propagated from dead blocks.
(We can certainly get rid of assertion; it is safe to do so, because propagating
 value from dead block to alive join node is certainly ok.)

  The root cause of this bug is : edge-splitting is conducted on the fly,
the edge being split could be a dead edge, therefore the block that 
split the critial edge needs to be flagged "dead" as well.

  There are 3 ways to fix this bug:
  1) Get rid of the assertion as I mentioned eariler 
  2) When an dead edge is split, flag the inserted block "dead".
  3) proactively split the critical edges connecting dead and live blocks when
     new dead blocks are revealed.

  This fix go for 3) with additional 2 LOC.

  Testing case was added by Rafael the other day.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194424 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-11 22:00:23 +00:00
Bill Wendling
855c29d82c Revert "Resurrect r191017 " GVN proceeds in the presence of dead code" plus a fix to PR17307 & 17308."
This causes PR17852.

This reverts commit d93e8a06b2.

Conflicts:
	test/Transforms/GVN/cond_br2.ll

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194348 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-10 07:34:34 +00:00
Shuxin Yang
d93e8a06b2 Resurrect r191017 " GVN proceeds in the presence of dead code" plus a fix to PR17307 & 17308.
The problem of r191017 is that when GVN fabricate a val-number for a dead instruction (in order
to make following expr-PRE happy), it forget to fabricate a leader-table entry for it as well.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191118 91177308-0d34-0410-b5e6-96231b3b80d8
2013-09-20 23:12:57 +00:00
Joerg Sonnenberger
fc572d87d2 Revert r191017, it results in segmentation faults in Qt.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191104 91177308-0d34-0410-b5e6-96231b3b80d8
2013-09-20 20:33:57 +00:00
Shuxin Yang
1bc7315c02 GVN proceeds in the presence of dead code.
This is how it ignores the dead code:
1) When a dead branch target, say block B, is identified, all the
    blocks dominated by B is dead as well.

2) The PHIs of those blocks in dominance-frontier(B) is updated such
   that the operands corresponding to dead predecessors are replaced
   by "UndefVal".

   Using lattice's jargon, the "UndefVal" is the "Top" in essence.
   Phi node like this "phi(v1 bb1, undef xx)" will be optimized into
   "v1" if v1 is constant, or v1 is an instruction which dominate this
   PHI node.

3) When analyzing the availability of a load L, all dead mem-ops which
   L depends on disguise as a load which evaluate exactly same value as L.

4) The dead mem-ops will be materialized as "UndefVal" during code motion.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191017 91177308-0d34-0410-b5e6-96231b3b80d8
2013-09-19 17:22:51 +00:00
Chris Lattner
0e959394ad remove a trivial test, make some other tests less trivial.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@131846 91177308-0d34-0410-b5e6-96231b3b80d8
2011-05-22 07:02:43 +00:00
Duncan Sands
cd6636c737 Teach InstructionSimplify about phi nodes. I chose to have it simply
offload the work to hasConstantValue rather than do something more
complicated (such handling mutually recursive phis) because (1) it is
not clear it is worth it; and (2) if it is worth it, maybe such logic
would be better placed in hasConstantValue.  Adjust some GVN tests
which are now cleaned up much further (eg: all phi nodes are removed).


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@119043 91177308-0d34-0410-b5e6-96231b3b80d8
2010-11-14 13:30:18 +00:00
Dan Gohman
c1be92f3bb Make BasicAliasAnalysis a normal AliasAnalysis implementation which
does normal initialization and normal chaining. Change the default
AliasAnalysis implementation to NoAlias.

Update StandardCompileOpts.h and friends to explicitly request
BasicAliasAnalysis.

Update tests to explicitly request -basicaa.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@116720 91177308-0d34-0410-b5e6-96231b3b80d8
2010-10-18 18:04:47 +00:00
Dan Gohman
f2f6ce65b7 Change tests from "opt %s" to "opt < %s" so that opt doesn't see the
input filename so that opt doesn't print the input filename in the
output so that grep lines in the tests don't unintentionally match
strings in the input filename.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@81537 91177308-0d34-0410-b5e6-96231b3b80d8
2009-09-11 18:01:28 +00:00
Dan Gohman
3e054fe9ef Use opt -S instead of piping bitcode output through llvm-dis.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@81257 91177308-0d34-0410-b5e6-96231b3b80d8
2009-09-08 22:34:10 +00:00
Dan Gohman
b1e1e82c54 Change these tests to feed the assembly files to opt directly, instead
of using llvm-as, now that opt supports this.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@81226 91177308-0d34-0410-b5e6-96231b3b80d8
2009-09-08 16:50:01 +00:00
Chris Lattner
4807e07fff Adjust testcase to make it more stable across visitation order changes,
unbreaking it after r61024.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61025 91177308-0d34-0410-b5e6-96231b3b80d8
2008-12-15 04:42:00 +00:00
Chris Lattner
f33131685b make GVN try to rename inputs to the resultant replaced values, which
cleans up the generated code a bit.  This should have the added benefit of
not randomly renaming functions/globals like my previous patch did. :)


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61023 91177308-0d34-0410-b5e6-96231b3b80d8
2008-12-15 03:46:38 +00:00
Bill Wendling
8295e49e76 Temporarily revert r60973. It's inexplicably causing a failure when self-hosting LLVM:
llvm[2]: Linking Release executable opt (without symbols)
...
Undefined symbols:
  "llvm::APFloat::IEEEsingle", referenced from:
      __ZN4llvm7APFloat10IEEEsingleE$non_lazy_ptr in libLLVMCore.a(Constants.o)
      __ZN4llvm7APFloat10IEEEsingleE$non_lazy_ptr in libLLVMCore.a(AsmWriter.o)
      __ZN4llvm7APFloat10IEEEsingleE$non_lazy_ptr in libLLVMCore.a(ConstantFold.o)
  "llvm::APFloat::IEEEdouble", referenced from:
      __ZN4llvm7APFloat10IEEEdoubleE$non_lazy_ptr in libLLVMCore.a(Constants.o)
      __ZN4llvm7APFloat10IEEEdoubleE$non_lazy_ptr in libLLVMCore.a(AsmWriter.o)
      __ZN4llvm7APFloat10IEEEdoubleE$non_lazy_ptr in libLLVMCore.a(ConstantFold.o)
ld: symbol(s) not found

This is in release mode. To replicate, compile llvm and llvm-gcc in optimized
mode. Then build llvm, in optimized mode, with the newly created compiler.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@60977 91177308-0d34-0410-b5e6-96231b3b80d8
2008-12-13 09:28:44 +00:00
Chris Lattner
879922932f make RLE preserve the name of the load that it replaces. This is just
a pretification of the IR.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@60973 91177308-0d34-0410-b5e6-96231b3b80d8
2008-12-13 07:22:47 +00:00
Owen Anderson
45537917ee Fix a couple more bugs in the phi construction by pulling in code that does
almost the same things from LCSSA.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@40540 91177308-0d34-0410-b5e6-96231b3b80d8
2007-07-26 18:26:51 +00:00