Expose LLVMCreateTargetMachineData as data_layout.

As r263530 did for go. From that commit: "LLVMGetTargetDataLayout was
removed from the C API, and then TargetMachine.TargetData was removed.
Later, LLVMCreateTargetMachineData was added to the C API"

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

llvm-svn: 265115

* LLVMDisposeMessage lives in llvm-c/Core.h, include this file where necessary
* LLVMAddTargetData has been removed, follow suit in the bindings

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

llvm-svn: 265001

Summary:
LLVMGetTargetDataLayout was removed from the C API,
and then TargetMachine.TargetData was removed. Later,
LLVMCreateTargetMachineData was added to the C API,
and we now expose this via the Go API.

Reviewers: deadalnix, pcc

Subscribers: cierniak, llvm-commits, axw

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

llvm-svn: 263530

Summary: It's red, it's dead.

Reviewers: joker.eph, Wallbraker, echristo

Subscribers: llvm-commits, axw

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

llvm-svn: 260919

llvm-svn: 260720

Summary:
LLVMGetTargetMachineData has been removed, and LLVMGetDataLayout is
suggested to use. The LLVMGetDataLayout is exposed in go bindings.
So it's safe to remove the function.

Reviewers: bkramer

Subscribers: llvm-commits, axw

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

llvm-svn: 260670

Summary:
This patch is provided in preparation for removing autoconf on 1/26. The proposal to remove autoconf on 1/26 was discussed on the llvm-dev thread here: http://lists.llvm.org/pipermail/llvm-dev/2016-January/093875.html

"I felt a great disturbance in the [build system], as if millions of [makefiles] suddenly cried out in terror and were suddenly silenced. I fear something [amazing] has happened."
- Obi Wan Kenobi

Reviewers: chandlerc, grosbach, bob.wilson, tstellarAMD, echristo, whitequark

Subscribers: chfast, simoncook, emaste, jholewinski, tberghammer, jfb, danalbert, srhines, arsenm, dschuff, jyknight, dsanders, joker.eph, llvm-commits

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

llvm-svn: 258861

This deprecates:
* LLVMParseBitcode
* LLVMParseBitcodeInContext
* LLVMGetBitcodeModuleInContext
* LLVMGetBitcodeModule

They are replaced with the functions with a 2 suffix which do not record
a diagnostic.

llvm-svn: 256065

Type specific declarations have been moved to Type.h and error handling
routines have been moved to ErrorHandling.h. Both are included in Core.h
so nothing should change for projects directly including the headers,
but transitive dependencies may be affected.

llvm-svn: 255965

Passing in a std::unique_ptr should help find errors when the module
is used after being linked into another module.

llvm-svn: 255842

Summary:
This patch does a couple of things:

  - Adds a new argument `--shared-mode` which accepts a list of components and prints whether or not the provided components need to be linked statically or shared.
  - Fixes `--libnames` when CMake BUILD_SHARED_LIBS is used.
  - Fixes `--libnames`, `--libs`, and `--libfiles` for dylib when static components aren't installed.
  - Fixes `--libnames`, `--libs`, `--libfiles`, and `--components` to use LLVM_DYLIB_COMPONENTS as the component manifest for dylib linking.
  - Uses the host platform's usual convention for filename extensions and such, instead of always defaulting to Unix-izms.

Because I don't own a Mac, I am not able to test the Mac platform dependent stuff locally. If someone would be willing to run a build for me on their machine (unless there's a better option), I'd appreciate it.

Reviewers: jfb, brad.king, whitequark, beanz

Subscribers: beanz, jauhien, llvm-commits

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

llvm-svn: 252532

Previously, subprograms contained a metadata reference to the function they
described. Because most clients need to get or set a subprogram for a given
function rather than the other way around, this created unneeded inefficiency.

For example, many passes needed to call the function llvm::makeSubprogramMap()
to build a mapping from functions to subprograms, and the IR linker needed to
fix up function references in a way that caused quadratic complexity in the IR
linking phase of LTO.

This change reverses the direction of the edge by storing the subprogram as
function-level metadata and removing DISubprogram's function field.

Since this is an IR change, a bitcode upgrade has been provided.

Fixes PR23367. An upgrade script for textual IR for out-of-tree clients is
attached to the PR.

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

llvm-svn: 252219

Patch by Jacques-Pascal Deplaix <jp.deplaix@gmail.com>

llvm-svn: 250912

Patch by Amaury Sechet with a small modification by me.

llvm-svn: 250374

Summary:
Update the Go bindings to DIBuilder to match
the split of creating local variables into
auto and parameter variables.

Reviewers: pcc

Subscribers: llvm-commits, axw

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

llvm-svn: 246935

folding the code into the main Analysis library.

There already wasn't much of a distinction between Analysis and IPA.
A number of the passes in Analysis are actually IPA passes, and there
doesn't seem to be any advantage to separating them.

Moreover, it makes it hard to have interactions between analyses that
are both local and interprocedural. In trying to make the Alias Analysis
infrastructure work with the new pass manager, it becomes particularly
awkward to navigate this split.

I've tried to find all the places where we referenced this, but I may
have missed some. I have also adjusted the C API to continue to be
equivalently functional after this change.

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

llvm-svn: 245318

Revert "Fix `llvm-config` to emit the linker flag for the combined shared object built by autoconfig/make instead of the individual components."

It seems I was wrong thinking `autoconf`/`make` only installed shared libraries if configured with `--enable-shared`, even if `--disable-static` is present. I'll re-address with a followup patch.

This reverts commit r243297 for causing PR#24154.

llvm-svn: 244108

Replace the general `createLocalVariable()` with two more specific
functions: `createParameterVariable()` and `createAutoVariable()`, and
rewrite the documentation.

Besides cleaning up the API, this avoids exposing the fake DWARF tags
`DW_TAG_arg_variable` and `DW_TAG_auto_variable` to frontends, and is
preparation for removing them completely.

llvm-svn: 243764

Fix `llvm-config` to emit the linker flag for the combined shared object built by autoconfig/make instead of the individual components.

Summary:
When LLVM is configured to build shared libraries, CMake builds each component as it's own shared object, while autoconfig/make builds them statically and then links them all together to create a single shared object. This change adds compile time config flags to `llvm-config` so it can know whether LLVM's components are separated or not and act accordingly.

This fixes `llvm-config` instead of fixing the makefiles to behave like CMake because, AIUI, LLVM's autoconfig/make build system is on the way out anyway.

This change only affects `llvm-config` from builds that use autoconfig/make.

Reviewers: jfb

Subscribers: echristo, dschuff, llvm-commits

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

llvm-svn: 243297

Revert the changes to the C API LLVMBuildLandingPad that were part of
the personality function move. We now set the personality on the parent
function when the C API attempts to construct a landingpad with a
personality.

This reverts commit r240010.

llvm-svn: 242372

Summary:
Add Value.SetPersonality to the Go bindings. The Go
bindings' Builder.CreateLandingPad has been updated,
removing the obsolete personality argument.

Background

The personality attribute was removed from LandingPadInst
in r239940, and llvm::Function::setPersonalityFn introduced.

There was no corresponding change to either the C API or
Go bindings. The Go bindings were broken until r239940, but
that change was just to ignore the personality argument.
This broke llgo.

Reviewers: majnemer, pcc

Subscribers: deadalnix, llvm-commits, axw

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

llvm-svn: 242289

Originally added in r139314.

Back then it didn't actually get the address, it got whatever value the
relocation used: address or offset.

The values in different object formats are:

* MachO: Always an offset.
* COFF: Always an address, but when talking about the virtual address of
  sections it says: "for simplicity, compilers should set this to zero".
* ELF: An offset for .o files and and address for .so files. In the case of the
  .so, the relocation in not linked to any section (sh_info is 0). We can't
  really compute an offset.

Some API mappings would be:

* Use getAddress for everything. It would be quite cumbersome. To compute the
  address elf has to follow sh_info, which can be corrupted and therefore the
  method has to return an ErrorOr. The address of the section is also the same
  for every relocation in a section, so we shouldn't have to check the error
  and fetch the value for every relocation.

* Use a getValue and make it up to the user to know what it is getting.

* Use a getOffset and:
 * Assert for dynamic ELF objects. That is a very peculiar case and it is
   probably fair to ask any tool that wants to support it to use ELF.h. The
   only tool we have that reads those (llvm-readobj) already does that. The
   only other use case I can think of is a dynamic linker.
 * Check that COFF .obj files have sections with zero virtual address spaces. If
   it turns out that some assembler/compiler produces these, we can change
   COFFObjectFile::getRelocationOffset to subtract it. Given COFF format,
   this can be done without the need for ErrorOr.

The getRelocationAddress method was never implemented for COFF. It also
had exactly one use in a very peculiar case: a shortcut for adding the
section value to a pcrel reloc on MachO.

Given that, I don't expect that there is any use out there of the C API. If
that is not the case, let me know and I will add it back with the implementation
inlined and do a proper deprecation.

llvm-svn: 241450

ctypes 0.3 and earlier contains an interface-definig bug:
its ptr_of_raw_address accepts Int64 and not Nativeint. ctypes 0.4
was not released during the 3.6 cycle, and because of that, LLVM 3.6
was released with ctypes 0.3 as a dependency, which now breaks
the build on modern ctypes.

Unbreak.

llvm-svn: 240882

any tests and I even don't know how to run the tests. This seems like a
minimal change to make them work again, although I can't really verify
at this point. Additionally, it probably makes sense to propagate the
personality parameter removal further.

llvm-svn: 240010

constants in commented-out part of LLVMAttribute enum. Add tests that verify
that the safestack attribute is only allowed as a function attribute.

llvm-svn: 239772

Finish off PR23080 by renaming the debug info IR constructs from `MD*`
to `DI*`.  The last of the `DIDescriptor` classes were deleted in
r235356, and the last of the related typedefs removed in r235413, so
this has all baked for about a week.

Note: If you have out-of-tree code (like a frontend), I recommend that
you get everything compiling and tests passing with the *previous*
commit before updating to this one.  It'll be easier to keep track of
what code is using the `DIDescriptor` hierarchy and what you've already
updated, and I think you're extremely unlikely to insert bugs.  YMMV of
course.

Back to *this* commit: I did this using the rename-md-di-nodes.sh
upgrade script I've attached to PR23080 (both code and testcases) and
filtered through clang-format-diff.py.  I edited the tests for
test/Assembler/invalid-generic-debug-node-*.ll by hand since the columns
were off-by-three.  It should work on your out-of-tree testcases (and
code, if you've followed the advice in the previous paragraph).

Some of the tests are in badly named files now (e.g.,
test/Assembler/invalid-mdcompositetype-missing-tag.ll should be
'dicompositetype'); I'll come back and move the files in a follow-up
commit.

llvm-svn: 236120

Remove the `DIArray` and `DITypeArray` typedefs, preferring the
underlying types (`DebugNodeArray` and `MDTypeRefArray`, respectively).

llvm-svn: 235413

Delete the remaining subclasses of (the already deleted) `DIDescriptor`.
Part of PR23080.

llvm-svn: 235404

Delete subclasses of (the already defunct) `DIScope`, updating users to
use the raw pointers from the `Metadata` hierarchy directly.

llvm-svn: 235356

Delete subclasses of (the already deleted) `DIType` in favour of
directly using pointers from the `Metadata` hierarchy.

While `DICompositeType` wraps `MDCompositeTypeBase` and `DIDerivedType`
wraps `MDDerivedTypeBase`, most uses of each really meant the more
specific `MDCompositeType` and `MDDerivedType`.

llvm-svn: 235351

As a step toward killing `DIDescriptor` and its subclasses, remove it
from the `DIBuilder` API.  Replace the subclasses with appropriate
pointers from the new debug info hierarchy.  There are a couple of
possible surprises in type choices for out-of-tree frontends:

  - Subroutine types: `MDSubroutineType`, not `MDCompositeTypeBase`.
  - Composite types: `MDCompositeType`, not `MDCompositeTypeBase`.
  - Scopes: `MDScope`, not `MDNode`.
  - Generic debug info nodes: `DebugNode`, not `MDNode`.

This is part of PR23080.

llvm-svn: 235111

Change `DIBuilder::insertDeclare()` and `insertDbgValueIntrinsic()` to
take an `MDLocation*`/`DebugLoc` parameter which it attaches to the
created intrinsic.  Assert at creation time that the `scope:` field's
subprogram matches the variable's.  There's a matching `clang` commit to
use the API.

The context for this is PR22778, which is removing the `inlinedAt:`
field from `MDLocalVariable`, instead deferring to the `!dbg` location
attached to the debug info intrinsic.  The best way to ensure we always
have a `!dbg` attachment is to require one at creation time.  I'll be
adding verifier checks next, but this API change is the best way to
shake out frontend bugs.

Note: I added an `llvm_unreachable()` in `bindings/go` and passed in
`nullptr` for the `DebugLoc`.  The `llgo` folks will eventually need to
pass a valid `DebugLoc` here.

llvm-svn: 235041

r234262 changed some code in DIBuilderBindings.cpp to use the unwrap function
to unwrap debug metadata. The problem with this is that unwrap asserts that
its argument is non-null, which is not what we want in a number of places
in DIBuilder where the argument is optional. This change makes certain
arguments optional by adding null checks in places where it is required,
fixing the llgo build.

llvm-svn: 234428

Remove `MDTupleTypedArrayWrapper::operator MDTuple*()`, since it causes
ambiguity (at least in some [1] compilers [2]) when using indexes to
`MDTupleTypedArrayWrapper::operator[](unsigned)` that are convertible to
(but not the same as) `unsigned`.

[1]: http://lab.llvm.org:8011/builders/sanitizer-windows/builds/2308
[2]: http://lab.llvm.org:8011/builders/clang-cmake-mips/builds/4442

llvm-svn: 234326

Go bindings edition of r234255.

llvm-svn: 234262

Fixes llgo following Duncan's changes to debug info in r231082. llgo needs
to replace composite types, which are no longer represented using MDTuple.

llvm-svn: 231416

Add the enum "LLVMLinkerMode" back for backwards-compatibility and add the
linker mode parameter back to the "LLVMLinkModules" function. The paramter is
ignored and has no effect.

Patch provided by: Filip Pizlo
Reviewed by: Rafael and Sean

llvm-svn: 230988

Summary:
We extend the DIBuilder type, adding a method for creating
replaceable composite types. This is necessary for creating
debug info describing self-referential types.

Reviewers: pcc

Reviewed By: pcc

Subscribers: axw, llvm-commits

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

llvm-svn: 230951

LLVM's include tree and the use of using declarations to hide the
'legacy' namespace for the old pass manager.

This undoes the primary modules-hostile change I made to keep
out-of-tree targets building. I sent an email inquiring about whether
this would be reasonable to do at this phase and people seemed fine with
it, so making it a reality. This should allow us to start bootstrapping
with modules to a certain extent along with making it easier to mix and
match headers in general.

The updates to any code for users of LLVM are very mechanical. Switch
from including "llvm/PassManager.h" to "llvm/IR/LegacyPassManager.h".
Qualify the types which now produce compile errors with "legacy::". The
most common ones are "PassManager", "PassManagerBase", and
"FunctionPassManager".

llvm-svn: 229094

miss previously.

llvm-svn: 229089