1
0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-10-19 11:02:59 +02:00
Commit Graph

16 Commits

Author SHA1 Message Date
Meador Inge
c24a74205b IR: Don't constant fold GEP bitcasts between different address spaces
PR15262 reported a bug where the following instruction:

  i8 getelementptr inbounds i8* bitcast ([4 x i8] addrspace(12)* @buf to i8*),
                                i32 2

was getting folded into:

  addrspace(12)* getelementptr inbounds ([4 x i8] addrspace(12)* @buf, i32 0,
                                        i32 2)

This caused instcombine to crash because the original instruction and
the folded instruction have different types.  The issue was fixed by
disallowing bitcasts between different address spaces to be folded away.

llvm-svn: 176156
2013-02-27 02:26:42 +00:00
Bill Wendling
74351693ea Modify the LLVM assembly output so that it uses references to represent function attributes.
This makes the LLVM assembly look better. E.g.:

     define void @foo() #0 { ret void }
     attributes #0 = { nounwind noinline ssp }

llvm-svn: 175605
2013-02-20 07:21:42 +00:00
Dan Gohman
25a863dcf7 Reapply r155682, making constant folding more consistent, with a fix to work
properly with how the code handles all-undef PHI nodes.

llvm-svn: 155721
2012-04-27 17:50:22 +00:00
NAKAMURA Takumi
a28147f072 Revert r155682, "Use ConstantExpr::getExtractElement when constant-folding vectors"
It broke stage2 build. stage1/clang sometimes crashed.

llvm-svn: 155699
2012-04-27 07:59:20 +00:00
Dan Gohman
a72b2f97a6 Use ConstantExpr::getExtractElement when constant-folding vectors
instead of getAggregateElement. This has the advantage of being
more consistent and allowing higher-level constant folding to
procede even if an inner extract element cannot be folded.

Make ConstantFoldInstruction call ConstantFoldConstantExpression
on the instruction's operands, making it more consistent with 
ConstantFoldConstantExpression itself. This makes sure that
ConstantExprs get TargetData-aware folding before being handed
off as operands for further folding.

This causes more expressions to be folded, but due to a known
shortcoming in constant folding, this currently has the side effect
of stripping a few more nuw and inbounds flags in the non-targetdata
side of constant-fold-gep.ll. This is mostly harmless.

This fixes rdar://11324230.

llvm-svn: 155682
2012-04-27 00:54:36 +00:00
Eli Friedman
09abc453ac Fix test.
llvm-svn: 146642
2011-12-15 04:52:47 +00:00
Eli Friedman
f6ae3a7caf Make constant folding for GEPs a bit more aggressive.
llvm-svn: 146639
2011-12-15 04:33:48 +00:00
Chris Lattner
a106725fc5 Land the long talked about "type system rewrite" patch. This
patch brings numerous advantages to LLVM.  One way to look at it
is through diffstat:
 109 files changed, 3005 insertions(+), 5906 deletions(-)

Removing almost 3K lines of code is a good thing.  Other advantages
include:

1. Value::getType() is a simple load that can be CSE'd, not a mutating
   union-find operation.
2. Types a uniqued and never move once created, defining away PATypeHolder.
3. Structs can be "named" now, and their name is part of the identity that
   uniques them.  This means that the compiler doesn't merge them structurally
   which makes the IR much less confusing.
4. Now that there is no way to get a cycle in a type graph without a named
   struct type, "upreferences" go away.
5. Type refinement is completely gone, which should make LTO much MUCH faster
   in some common cases with C++ code.
6. Types are now generally immutable, so we can use "Type *" instead 
   "const Type *" everywhere.

Downsides of this patch are that it removes some functions from the C API,
so people using those will have to upgrade to (not yet added) new API.  
"LLVM 3.0" is the right time to do this.

There are still some cleanups pending after this, this patch is large enough
as-is.

llvm-svn: 134829
2011-07-09 17:41:24 +00:00
Chris Lattner
ecf276b787 remove unions from LLVM IR. They are severely buggy and not
being actively maintained, improved, or extended.

llvm-svn: 112356
2010-08-28 04:09:24 +00:00
Dan Gohman
d9d4889ccc Constant-fold GEP-of-GEP into a single GEP.
llvm-svn: 98178
2010-03-10 19:31:51 +00:00
Dan Gohman
7fa1298057 Fix whitespace.
llvm-svn: 98173
2010-03-10 19:00:54 +00:00
Dan Gohman
a15e497d94 Teach the constant folder about union types.
llvm-svn: 97142
2010-02-25 16:45:19 +00:00
Dan Gohman
ff8027e33a Canonicalize sizeof and alignof on pointer types to a canonical
pointer type.

llvm-svn: 95769
2010-02-10 06:13:07 +00:00
Dan Gohman
dd6702be8f Factor out alignof expression folding into a separate function and
generalize it to handle more cases.

llvm-svn: 95045
2010-02-02 01:41:39 +00:00
Dan Gohman
0b2c2769ba Generalize target-independent folding rules for sizeof to handle more
cases, and implement target-independent folding rules for alignof and
offsetof. Also, reassociate reassociative operators when it leads to
more folding.

Generalize ScalarEvolution's isOffsetOf to recognize offsetof on
arrays. Rename getAllocSizeExpr to getSizeOfExpr, and getFieldOffsetExpr
to getOffsetOfExpr, for consistency with analagous ConstantExpr routines.

Make the target-dependent folder promote GEP array indices to
pointer-sized integers, to make implicit casting explicit and exposed
to subsequent folding.

And add a bunch of testcases for this new functionality, and a bunch
of related existing functionality.

llvm-svn: 94987
2010-02-01 18:27:38 +00:00
Dan Gohman
0dc9176f36 Remove the folding rule
getelementptr (i8* inttoptr (i64 1 to i8*), i32 -1) 
  to
  inttoptr (i64 0 to i8*)
from the VMCore constant folder. It didn't handle sign-extension properly
in the case where the source integer is smaller than a pointer size. And,
it relied on an assumption about sizeof(i8).

The Analysis constant folder still folds these kinds of things; it has
access to TargetData, so it can do them right.

Add a testcase which tests that the VMCore constant folder doesn't
miscompile this, and that the Analysis folder does fold it.

llvm-svn: 94750
2010-01-28 18:08:26 +00:00