- Make CallGraphSCCPass's paragraph about doFinalization refer to
  runOnSCC instead of runOnFunction, since that's what it's about.
- Fix a reference in the FunctionPass paragraph.

llvm-svn: 222222

This was done using the Sparc and PowerPC AsmParsers as guides.  So far it
is very simple and only supports sopp instructions.

llvm-svn: 221994

Patch by Palmer Dabbelt!

llvm-svn: 221638

The old examples had missing/incorrect flags that were causing failures on newer
versions of clang and the tutorial code.

llvm-svn: 221419

llvm-svn: 221406

Patch by Steve King.

llvm-svn: 221227

The given example was overflowing its alloca and segfaulting if actually run on
x86, so it's a good idea to provide something that works there too.

Patch by Ramkumar Ramachandra.

llvm-svn: 221077

llvm-svn: 220838

When several build targets, e.g. Debug+Asserts and Release+Asserts
are present, ocamldoc complains of duplicate interfaces.

llvm-svn: 220831

llvm.donothing is no longer the only intrinsic that can be invoked.

llvm-svn: 220530

llvm-svn: 220402

llvm-svn: 220352

These are named following the IEEE-754 names for these
functions, rather than the libm fmin / fmax to avoid
possible ambiguities. Some languages may implement something
resembling fmin / fmax which return NaN if either operand is
to propagate errors. These implement the IEEE-754 semantics
of returning the other operand if either is a NaN representing
missing data.

llvm-svn: 220341

The newly introduced 'nonnull' metadata is analogous to existing 'nonnull' attributes, but applies to load instructions rather than call arguments or returns.  Long term, it would be nice to combine these into a single construct.   The value of the load is allowed to vary between successive loads, but null is not a valid value to be loaded by any load marked nonnull.

Reviewed by: Hal Finkel
Differential Revision:  http://reviews.llvm.org/D5220

llvm-svn: 220240

llvm-symbolizer will consult one of the .dSYM paths passed via -dsym-hint
if it fails to find the .dSYM bundle at the default location.

llvm-svn: 220004

These days -std-compile-opts was just a silly alias for -O3.

llvm-svn: 219951

llvm-svn: 219947

Rather than define our own standards, we adopt a set of best practices that
are already in use by the Go community.

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

llvm-svn: 219646

match the current implementation.

Patch by Douglas Yung!

llvm-svn: 219631

Summary:
We currently emit an DW_AT_APPLE_property_attribute with a value that is a
bitfield describing the various attributes applied to an ObjectiveC property.
While trying to add testing to one of my dwarfdump patches that would pretty
print that, I realized this information looks totally broken and has maybe
never been correct.

As with every DWARF info, we have some enum in Dwarf.h that describes this
attribute (enum ApplePropertyAttributes). It seems however that the attribute
value is set from another definition of these flags in Sema/DeclSpec.h (enum
ObjCPropertyAttributeKind). And these 2 enums aren't in sync.

This patch updates the Dwarf.h values to the ones we are (and have been for
a very long time) emitting. We change some publicly (and even documented
in SourceLevelDebugging.rst) values, but I doubt this could be an issue as
the information has been wrong for so long...

Reviewers: echristo, dblaikie, aprantl

Subscribers: llvm-commits

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

llvm-svn: 219311

llvm-svn: 219134

llvm-svn: 219056

llvm-svn: 219055

llvm-svn: 219054

llvm-svn: 219053

Update a couple of the examples of debug info metadata, and prune the
rest.  Point to the true reference implementation in the source.

llvm-svn: 219051

llvm-svn: 219018

llvm-svn: 219015

This reverts commit r218918, effectively reapplying r218914 after fixing
an Ocaml bindings test and an Asan crash.  The root cause of the latter
was a tightened-up check in `DILexicalBlock::Verify()`, so I'll file a
PR to investigate who requires the loose check (and why).

Original commit message follows.

--

This patch addresses the first stage of PR17891 by folding constant
arguments together into a single MDString.  Integers are stringified and
a `\0` character is used as a separator.

Part of PR17891.

Note: I've attached my testcases upgrade scripts to the PR.  If I've
just broken your out-of-tree testcases, they might help.

llvm-svn: 219010

llvm-svn: 218982

Summary:
I changed various bits of the compilation of atomics recently, and forgot
updating the documentation. This patch just brings it up to date.

Test Plan: no change to the code

Reviewers: jfb

Subscribers: llvm-commits

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

llvm-svn: 218937

This reverts commit r218914 while I investigate some bots.

llvm-svn: 218918

This patch addresses the first stage of PR17891 by folding constant
arguments together into a single MDString.  Integers are stringified and
a `\0` character is used as a separator.

Part of PR17891.

Note: I've attached my testcases upgrade scripts to the PR.  If I've
just broken your out-of-tree testcases, they might help.

llvm-svn: 218914

argument of the llvm.dbg.declare/llvm.dbg.value intrinsics.

Previously, DIVariable was a variable-length field that has an optional
reference to a Metadata array consisting of a variable number of
complex address expressions. In the case of OpPiece expressions this is
wasting a lot of storage in IR, because when an aggregate type is, e.g.,
SROA'd into all of its n individual members, the IR will contain n copies
of the DIVariable, all alike, only differing in the complex address
reference at the end.

By making the complex address into an extra argument of the
dbg.value/dbg.declare intrinsics, all of the pieces can reference the
same variable and the complex address expressions can be uniqued across
the CU, too.
Down the road, this will allow us to move other flags, such as
"indirection" out of the DIVariable, too.

The new intrinsics look like this:
declare void @llvm.dbg.declare(metadata %storage, metadata %var, metadata %expr)
declare void @llvm.dbg.value(metadata %storage, i64 %offset, metadata %var, metadata %expr)

This patch adds a new LLVM-local tag to DIExpressions, so we can detect
and pretty-print DIExpression metadata nodes.

What this patch doesn't do:

This patch does not touch the "Indirect" field in DIVariable; but moving
that into the expression would be a natural next step.

http://reviews.llvm.org/D4919
rdar://problem/17994491

Thanks to dblaikie and dexonsmith for reviewing this patch!

Note: I accidentally committed a bogus older version of this patch previously.
llvm-svn: 218787

"Move the complex address expression out of DIVariable and into an extra"

llvm-svn: 218782

argument of the llvm.dbg.declare/llvm.dbg.value intrinsics.

Previously, DIVariable was a variable-length field that has an optional
reference to a Metadata array consisting of a variable number of
complex address expressions. In the case of OpPiece expressions this is
wasting a lot of storage in IR, because when an aggregate type is, e.g.,
SROA'd into all of its n individual members, the IR will contain n copies
of the DIVariable, all alike, only differing in the complex address
reference at the end.

By making the complex address into an extra argument of the
dbg.value/dbg.declare intrinsics, all of the pieces can reference the
same variable and the complex address expressions can be uniqued across
the CU, too.
Down the road, this will allow us to move other flags, such as
"indirection" out of the DIVariable, too.

The new intrinsics look like this:
declare void @llvm.dbg.declare(metadata %storage, metadata %var, metadata %expr)
declare void @llvm.dbg.value(metadata %storage, i64 %offset, metadata %var, metadata %expr)

This patch adds a new LLVM-local tag to DIExpressions, so we can detect
and pretty-print DIExpression metadata nodes.

What this patch doesn't do:

This patch does not touch the "Indirect" field in DIVariable; but moving
that into the expression would be a natural next step.

http://reviews.llvm.org/D4919
rdar://problem/17994491

Thanks to dblaikie and dexonsmith for reviewing this patch!

llvm-svn: 218778

llvm-svn: 218504

llvm-svn: 218448

llvm-svn: 218447

llvm-svn: 218319