------------------------------------------------------------------------
r155984 | void | 2012-05-02 02:59:45 -0700 (Wed, 02 May 2012) | 4 lines
The value held in the vector may be RAUW'ed by some of the canonicalization
methods. Use a weak value handle to keep up with this.
PR12245
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_31@155985 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r155954 | void | 2012-05-01 15:50:45 -0700 (Tue, 01 May 2012) | 3 lines
Strip the pointer casts off of allocas so that the selection DAG can find them.
PR10799
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_31@155955 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r155902 | void | 2012-05-01 01:27:43 -0700 (Tue, 01 May 2012) | 7 lines
Change the PassManager from a reference to a pointer.
The TargetPassManager's default constructor wants to initialize the PassManager
to 'null'. But it's illegal to bind a null reference to a null l-value. Make the
ivar a pointer instead.
PR12468
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_31@155903 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r155895 | eliben | 2012-04-30 23:15:40 -0700 (Mon, 30 Apr 2012) | 4 lines
Removed examples of stack frame inspection which no longer work for old JIT.
Added an example of MCJIT-based debugging.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_31@155901 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r155844 | spop | 2012-04-30 13:06:58 -0700 (Mon, 30 Apr 2012) | 8 lines
fix typo
Thanks to "Gabor Greif" <ggreif@gmail.com> for reporting this problem.
The configure flag should be --with-default-sysroot as documented, and
not --with-sysroot. The reason we don't want to define --with-sysroot
is that GCC has a configure flag by that name and it has a different
semantics.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_31@155852 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r155817 | void | 2012-04-30 03:44:54 -0700 (Mon, 30 Apr 2012) | 9 lines
Second attempt at PR12573:
Allow the "SplitCriticalEdge" function to split the edge to a landing pad. If
the pass is *sure* that it thinks it knows what it's doing, then it may go ahead
and specify that the landing pad can have its critical edge split. The loop
unswitch pass is one of these passes. It will split the critical edges of all
edges coming from a loop to a landing pad not within the loop. Doing so will
retain important loop analysis information, such as loop simplify.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_31@155833 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r155813 | void | 2012-04-30 02:23:48 -0700 (Mon, 30 Apr 2012) | 1 line
Remove hack from r154987. The problem persists even with it, so it's not even a good hack.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_31@155831 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r155809 | rafael | 2012-04-29 20:53:06 -0700 (Sun, 29 Apr 2012) | 2 lines
Make sure HoistInsertPosition finds a position that is dominated by all
inputs.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_31@155828 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r155818 | baldrick | 2012-04-30 04:56:58 -0700 (Mon, 30 Apr 2012) | 3 lines
Just mark the sign bit as known zero, rather than any other irrelevant bits
known zero in the LHS. Fixes PR12541.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_31@155827 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r155668 | atrick | 2012-04-26 14:48:25 -0700 (Thu, 26 Apr 2012) | 8 lines
Fix the SD scheduler to avoid gluing the same node twice.
DAGCombine strangeness may result in multiple loads from the same
offset. They both may try to glue themselves to another load. We could
insist that the redundant loads glue themselves to each other, but the
beter fix is to bail out from bad gluing at the time we detect it.
Fixes rdar://11314175: BuildSchedUnits assert.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_31@155672 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r155466 | chandlerc | 2012-04-24 11:42:47 -0700 (Tue, 24 Apr 2012) | 17 lines
Fix a crash on valid (if UB) bitcode that is produced for some global
constants in C++11 mode. I have no idea why it required such particular
circumstances to get here, the code seems clearly to rely upon unchecked
assumptions.
Specifically, when we decide to form an index into a struct type, we may
have gone through (at least one) zero-length array indexing round, which
would have left the offset un-adjusted, and thus not necessarily valid
for use when indexing the struct type.
This is just an canonicalization step, so the correct thing is to refuse
to canonicalize nonsensical GEPs of this form. Implemented, and test
case added.
Fixes PR12642. Pair debugged and coded with Richard Smith. =] I credit
him with most of the debugging, and preventing me from writing the wrong
code.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_31@155506 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r155288 | d0k | 2012-04-21 09:05:27 -0700 (Sat, 21 Apr 2012) | 6 lines
Remove unused PointerLikeTypeTraits for IndexListEntry.
It set NumLowBitAvailable = 3 which may not be true on all platforms. We only
ever use 2 bits (the default) so this assumption can be safely removed
Should fix PR12612.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_31@155375 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r155285 | chapuni | 2012-04-21 07:51:02 -0700 (Sat, 21 Apr 2012) | 1 line
CMake: Enable LLVM_COMPILER_JOBS on all MS IDEs. We don't support older environments than VS9.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_31@155335 91177308-0d34-0410-b5e6-96231b3b80d8
If the loop contains invoke instructions, whose unwind edge escapes the loop,
then don't try to unswitch the loop. Doing so may cause the unwind edge to be
split, which not only is non-trivial but doesn't preserve loop simplify
information.
Fixes PR12573
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@154987 91177308-0d34-0410-b5e6-96231b3b80d8
obviously cannot know that this code is present, let alone used. So prevent the
internalize pass from internalizing those global values which code-gen may
insert.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@154645 91177308-0d34-0410-b5e6-96231b3b80d8
StringMap. This was redundant and unnecessarily bloated the MDString class.
Because the MDString class is a "Value" and will never have a "name", and
because the Name field in the Value class is a pointer to a StringMap entry, we
repurpose the Name field for an MDString. It stores the StringMap entry in the
Name field, and uses the normal methods to get the string (name) back.
PR12474
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@154429 91177308-0d34-0410-b5e6-96231b3b80d8
An MDNode has a list of MDNodeOperands allocated directly after it as part of
its allocation. Therefore, the Parent of the MDNodeOperands can be found by
walking back through the operands to the beginning of that list. Mark the first
operand's value pointer as being the 'first' operand so that we know where the
beginning of said list is.
This saves a *lot* of space during LTO with -O0 -g flags.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@154280 91177308-0d34-0410-b5e6-96231b3b80d8
Consider the following program:
$ cat main.c
void foo(void) { }
int main(int argc, char *argv[]) {
foo();
return 0;
}
$ cat bundle.c
extern void foo(void);
void bar(void) {
foo();
}
$ clang -o main main.c
$ clang -o bundle.so bundle.c -bundle -bundle_loader ./main
$ nm -m bundle.so
0000000000000f40 (__TEXT,__text) external _bar
(undefined) external _foo (from executable)
(undefined) external dyld_stub_binder (from libSystem)
$ clang -o main main.c -O4
$ clang -o bundle.so bundle.c -bundle -bundle_loader ./main
Undefined symbols for architecture x86_64:
"_foo", referenced from:
_bar in bundle-elQN6d.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
The linker was told that the 'foo' in 'main' was 'internal' and had no uses, so
it was dead stripped.
Another situation is something like:
define void @foo() {
ret void
}
define void @bar() {
call asm volatile "call _foo" ...
ret void
}
The only use of 'foo' is inside of an inline ASM call. Since we don't look
inside those for uses of functions, we don't specify this as a "use."
Get around this by not invoking the 'internalize' pass by default. This is an
admitted hack for LTO correctness.
<rdar://problem/11185386>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@154124 91177308-0d34-0410-b5e6-96231b3b80d8
reflected in the LLVM IR (as a declare or something), then treat it like a data
object.
N.B. This isn't 100% correct. The ASM parser should supply more information so
that we know what type of object it is, and what attributes it should have.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153870 91177308-0d34-0410-b5e6-96231b3b80d8
definition for it. In that case, we want to wait for the potential definition
before we create a symbol for it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153859 91177308-0d34-0410-b5e6-96231b3b80d8
here but it has no other uses, then we have a problem. E.g.,
int foo (const int *x) {
char a[*x];
return 0;
}
If we assign 'a' a vreg and fast isel later on has to use the selection
DAG isel, it will want to copy the value to the vreg. However, there are
no uses, which goes counter to what selection DAG isel expects.
<rdar://problem/11134152>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153705 91177308-0d34-0410-b5e6-96231b3b80d8
Module-level ASM may contain definitions of functions and globals. However, we
were not telling the linker that these globals had definitions. As far as it was
concerned, they were just declarations.
Attempt to resolve this by inserting module-level ASM functions and globals into
the '_symbol' set so that the linker will know that they have values.
This gets us further towards our goal of compiling LLVM, but it still has
problems when linking libLTO.dylib because of the `-dead_strip' flag that's
passed to the linker.
<rdar://problem/11124216>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153638 91177308-0d34-0410-b5e6-96231b3b80d8
executable has been moved to another machine). If that's not available
(read-only or something), then exit gracefully.
<rdar://problem/11111686>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153538 91177308-0d34-0410-b5e6-96231b3b80d8
destination module, but one of them isn't used in the destination module. If
another module comes along and the uses the unused type, there could be type
conflicts when the modules are finally linked together. (This happened when
building LLVM.)
The test that was reduced is:
Module A:
%Z = type { %A }
%A = type { %B.1, [7 x x86_fp80] }
%B.1 = type { %C }
%C = type { i8* }
declare void @func_x(%C*, i64, i64)
declare void @func_z(%Z* nocapture)
Module B:
%B = type { %C.1 }
%C.1 = type { i8* }
%A.2 = type { %B.3, [5 x x86_fp80] }
%B.3 = type { %C.1 }
define void @func_z() {
%x = alloca %A.2, align 16
%y = getelementptr inbounds %A.2* %x, i64 0, i32 0, i32 0
call void @func_x(%C.1* %y, i64 37, i64 927) nounwind
ret void
}
declare void @func_x(%C.1*, i64, i64)
declare void @func_y(%B* nocapture)
(Unfortunately, this test doesn't fail under llvm-link, only during an LTO
linking.) The '%C' and '%C.1' clash. The destination module gets the '%C'
declaration. When merging Module B, it looks at the '%C.1' subtype of the '%B'
structure. It adds that in, because that's cool. And when '%B.3' is processed,
it uses the '%C.1'. But the '%B' has used '%C' and we prefer to use '%C'. So the
'@func_x' type is changed to 'void (%C*, i64, i64)', but the type of '%x' in
'@func_z' remains '%A.2'. The GEP resolves to a '%C.1', which conflicts with the
'@func_x' signature.
We can resolve this situation by making sure that the type is used in the
destination before saying that it should be used in the module being merged in.
With this fix, LLVM and Clang both compile under LTO.
<rdar://problem/10913281>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153351 91177308-0d34-0410-b5e6-96231b3b80d8
few comments where none existed before. Also change a function's name to match
the current coding standard.
No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153276 91177308-0d34-0410-b5e6-96231b3b80d8
i128). In that case, we may not be able to print out the MCExpr as an
expression. For instance, we could have an MCExpr like this:
0xBEEF0000BEEF0000 | (0xBEEF0000BEEF0000 << 64)
The MCExpr printer handles sizes up to 64-bits, but this expression would
require 128-bits. In this situation, try to evaluate the constant expression and
emit that as the value into 64-bit chunks.
<rdar://problem/11070338>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153081 91177308-0d34-0410-b5e6-96231b3b80d8
fast-isel before emitting code. If the program bails after code was emitted,
then it could lead to the stack being adjusted more than once (two
CALLSEQ_BEGINs emitted) but being adjuste back only once after the call. This
leads to general badness and gnashing of teeth.
<rdar://problem/11050630>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@152959 91177308-0d34-0410-b5e6-96231b3b80d8
alignment. If that's the case, then we want to make sure that we don't increase
the alignment of the store instruction. Because if we increase it to be "more
aligned" than the pointer, code-gen may use instructions which require a greater
alignment than the pointer guarantees.
<rdar://problem/11043589>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@152907 91177308-0d34-0410-b5e6-96231b3b80d8
There were cases where a value could be used and it's both crossing an invoke
and NOT crossing an invoke. This could happen in the landing pads. In that case,
we will demote the value to the stack like we did before.
<rdar://problem/10609139>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@152705 91177308-0d34-0410-b5e6-96231b3b80d8
expensive "getFirstTerminator" call. This reduces the time of compilation in
PR12258 from >10 minutes to < 10 seconds.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@152704 91177308-0d34-0410-b5e6-96231b3b80d8
Bill Wendling