The former implementation passed the platina type and expression
infromation by means of two metadata items attached to the intrinsic
call instruction. However, the tail-call-optimization dropped this
metadata (in sync with the docs):

  A transformation is required to drop any metadata attachment that it
  does not know or know it can’t preserve.

Passing this data by means of operands to the call instruction should
be more robust.

We have to mangle module-internal machinefunction names. The syntax is
now:
  modulename =~ s/[^0-9A-Za-z]/_/g
  modulename + '_' + functionname

Rational is to be able to bound loopiterations on model level.
Syntax is `#pragma platina lbound <num>` even though this syntax is not
final yet.

Rational is to be able to annotate the target set of function pointers.
Syntax is `#pragma platina callee [f1, f2, ...]`.

This commit adds the ability to propagate platina annotations to the
machinecode level. There is now a generic mechanism that propagates the
metadata pair `platina.type` and `platina.expr` as strings from a
IR-Level platina-intrinsic to machinecode.

The facts are exported to the modelfacts member in the PML-files.
Syntax is as follows:

```YAML
modelfacts:
  - program-point:
      function:        c_entry
      block:           if.else
    origin:          platina.bc
    level:           bitcode
    type:            guard
    expression:      'false'
```

This commit adds a platina intrinsic, which is used as metadata
container for annotations. This container degrades to a simple platina
intrinsic opcode, with no parameters.
This switch from Bitcode to Machinecode happens in
CodeGen/SelectionDAG, which the metadata.
We prohibit this opcode from lowering.

Linkage information on Functions with `ExternalLinkage` was not emitted
to YAML.

From the docs:
	http://llvm.org/docs/YamlIO.html
"There is one important difference between those two ways (default
constructor and third parameter to mapOptional). When YAML I/O generates
a YAML document, if the mapOptional() third parameter is used, if the
actual value being written is the same as (using ==) the default value,
then that key/value is not written."

This commit exports a functions LinkageType to PML for both
MachineFunctions and BitcodeFunctions.

Hacky. Renames functions with local or private linkage to
"$funcname_sanitize($modulename)". Sanitize does 's/[^a-zA-Z0-9_]/_/g'

This is kind of a hack. Assigns a method local unique basic block name
to each unnamed basic block in the function.

The `setSrcLocOnce` function wrongly rejected scoped `DebugLoc`
instances after the assert was refactored between 3.4 and 3.8.
See the comment in the sourcefile for details.

The handling of synthetic basic blocks such as "entry" blocks was
changed between llvm 3.4 and llvm 3.8, which resulted in internal
assertions being triggered.
Checking for invalid values obviously helps...

The -mserialize-all option forces llc to not only serialize data for all
functions reachable from the specified root function (e.g., main), but for all
functions in the module.

Both `PatmosMCTargetDecs.cpp` as well as `PatmosSubtarget.cpp` include
`PatmosGenSubtargetInfo.inc` with `#define GET_SUBTARGETINFO_MC_DESC`.

This is used to provide definitions for serveral global arrays and
constants. As a result, those definitions end up in both objectfiles,
which therefore fail to link.

This patch resolves this conflict by exposing the necessary values for
`PatmosSubtarget.cpp` as functions from `PatmosMCTargetDesc.cpp`, which
from now on holds the instances.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_38@262542 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_38@262537 91177308-0d34-0410-b5e6-96231b3b80d8