metadata.

llvm-svn: 153359

some calling code to actually pass in a non-null type, to avoid a crash.

llvm-svn: 153358

llvm-svn: 153356

just because there was an attribute in front of it.

llvm-svn: 153355

managed to insert an @interface as top level decl contained by another
@interface.

A commit to also not allow this as valid code will be coming.

rdar://11105114.

llvm-svn: 153354

llvm-svn: 153353

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>

llvm-svn: 153351

forward-declared enums aren't /quite/ done yet.

llvm-svn: 153350

a previous declaration if the redeclaration is invalid. That way lies madness.
Fixes a crash-on-invalid reported by Abramo.

llvm-svn: 153349

Patch by Simon Atanasyan.

llvm-svn: 153348

No functional change, just tidy up the code and nomenclature a bit.

llvm-svn: 153347

Dump the hex representation to the comment stream as well as the float
value.

llvm-svn: 153346

entries in the relocation table before they are written out to the file. 

llvm-svn: 153345

is retaining the return value of an invoke that it immediately follows.

llvm-svn: 153344

same basic block, and it's not safe to insert code in the successor
blocks if the edges are critical edges. Splitting those edges is
possible, but undesirable, especially on the unwind side. Instead,
make the bottom-up code motion to consider invokes to be part of
their successor blocks, rather than part of their parent blocks, so
that it doesn't push code past them and onto the edges. This fixes
PR12307.

llvm-svn: 153343

Make it feasible for clients using EngineBuilder to capture the TargetMachine that is created as part of selecting the appropriate target.
This is necessary if the client wants to be able to mutate TargetOptions (for example, fast FP math mode) after the initial creation of the ExecutionEngine.

llvm-svn: 153342

llvm-svn: 153341

llvm-svn: 153333

llvm-svn: 153332

llvm-svn: 153331

llvm-svn: 153330

This should unbreak the msvc build.

llvm-svn: 153329

llvm-svn: 153328

llvm-svn: 153327

New code should use raw_ostream.

llvm-svn: 153326

We create a new file LoopGenerators that provides utility classes for the
generation of OpenMP parallel and scalar loops. This means we move a lot
of the OpenMP generation out of the Polly specific code generator.

llvm-svn: 153325

Patch from Mageia!

llvm-svn: 153324

dominated by Root, check that B is available throughout the scope.  This
is obviously true (famous last words?) given the current logic, but the
check may be helpful if more complicated reasoning is added one day.

llvm-svn: 153323

llvm-svn: 153322

No functional changes intended.

llvm-svn: 153321

The prefix is not needed, as all test cases are already in a separate folder.

llvm-svn: 153320

This also adds support for modifiable write accesses (until now only read
accesses where supported). We currently do not derive an exact type for the
expression, but assume that i64 is good enough. This will be improved in future
patches.

Contributed by: Yabin Hu <yabin.hwu@gmail.com>

llvm-svn: 153319

This functionality is not available in LLVM trunk and breaks the compilation of
Polly. This patch fixes the compilation, but may not be enough to recover all
functionality.

llvm-svn: 153318

Contributed-By: Andrew Trick <atrick@apple.com>
llvm-svn: 153317

llvm-svn: 153316

llvm-svn: 153315

llvm-svn: 153314

of memory during LTO.

llvm-svn: 153313

llvm-svn: 153312

Avoid applying retain/release effects twice in RetainCountChecker when a function call was inlined (i.e., we do not need to apply summaries in such cases).

llvm-svn: 153309