Per the October 12, 2012 Proposal for annotated disassembly output sent out by
Jim Grosbach this set of changes implements this for X86 and arm.  The llvm-mc
tool now has a -mdis option to produced the marked up disassembly and a couple
of small example test cases have been added.

rdar://11764962

llvm-svn: 166445

llvm-svn: 166376

Move the Attributes::Builder outside of the Attributes class and into its own class named AttrBuilder. No functionality change.

llvm-svn: 165960

Resubmit the changes to llvm core to update the functions to support different pointer sizes on a per address space basis.

llvm-svn: 165941

llvm-svn: 165890

llvm-svn: 165747

Add in the first iteration of support for llvm/clang/lldb to allow variable per address space pointer sizes to be optimized correctly.

llvm-svn: 165726

llvm-svn: 165461

llvm-svn: 165402

Anthony Bryant.

llvm-svn: 164247

Rationale: For each preprocessor macro, either the definedness is what's
meaningful, or the value is what's meaningful, or both. If definedness is
meaningful, we should use #ifdef. If the value is meaningful, we should use
and #ifdef interchangeably for the same macro, seems ugly to me, even if
undefined macros are zero if used.

This also has the benefit that including an LLVM header doesn't prevent
you from compiling with -Wundef -Werror.

Patch by John Garvin!
<rdar://problem/12189979>

llvm-svn: 163148

replace a couple of single-line comments with /* */ to fix the build of stuff depending on the C headers

llvm-svn: 163095

make it more consistent with its intended semantics.

The `linker_private_weak_def_auto' linkage type was meant to automatically hide
globals which never had their addresses taken. It has nothing to do with the
`linker_private' linkage type, which outputs the symbols with a `l' (ell) prefix
among other things.

The intended semantic is more like the `linkonce_odr' linkage type.

Change the name of the linkage type to `linkonce_odr_auto_hide'. And therefore
changing the semantics so that it produces the correct output for the linker.

Note: The old linkage name `linker_private_weak_def_auto' will still parse but
is not a synonym for `linkonce_odr_auto_hide'. This should be removed in 4.0.
<rdar://problem/11754934>

llvm-svn: 162114

llvm-svn: 161678

llvm-svn: 161677

llvm-svn: 160473

This was always part of the VMCore library out of necessity -- it deals
entirely in the IR. The .cpp file in fact was already part of the VMCore
library. This is just a mechanical move.

I've tried to go through and re-apply the coding standard's preferred
header sort, but at 40-ish files, I may have gotten some wrong. Please
let me know if so.

I'll be committing the corresponding updates to Clang and Polly, and
Duncan has DragonEgg.

Thanks to Bill and Eric for giving the green light for this bit of cleanup.

llvm-svn: 159421

llvm-svn: 157885

This lets you save the textual representation of the LLVM IR to a file.
Before this patch it could only be printed to STDERR from llvm-c.

Patch by Carlo Kok!

llvm-svn: 156479

Patch by Andrew Wilkins!

llvm-svn: 156469

This avoids warnings when included in a application that
uses -Wstrict-prototypes. 

e.g: AsmPrinters.def:27:1: warning: function declaration isn't a prototype [-Wstrict-prototypes]

llvm-svn: 155997

so we don't want it to show up in the stable 3.1 interface.

While at it, add a comment about why LTOCodeGenerator manually creates the
internalize pass.

llvm-svn: 154807

binary and assembly. Patch by Carlo Kok.  Emitting was inspired by but not based
on the D llvm bindings. 

llvm-svn: 154493

llvm-svn: 154312

llvm-svn: 154306

llvm-svn: 153802

llvm-svn: 153479

llvm-svn: 153238

Remaining "uncategorized" functions have been organized into their
proper place in the hierarchy. Some functions were moved around so
groups are defined together.

No code changes were made.

llvm-svn: 153169

This gives a lot of love to the docs for the C API. Like Clang's
documentation, the C API is now organized into a Doxygen "module"
(LLVMC). Each C header file is a child of the main module. Some modules
(like Core) have a hierarchy of there own. The produced documentation is
thus better organized (before everything was in one monolithic list).

This patch also includes a lot of new documentation for APIs in Core.h.
It doesn't document them all, but is better than none. Function docs are
missing @param and @return annotation, but the documentation body now
commonly provides help details (like the expected llvm::Value sub-type
to expect).

llvm-svn: 153157

were no 'unwind' instructions being generated before this, so this is in effect
a no-op.

llvm-svn: 149906

llvm-svn: 149472

This is the initial checkin of the basic-block autovectorization pass along with some supporting vectorization infrastructure.
Special thanks to everyone who helped review this code over the last several months (especially Tobias Grosser).

llvm-svn: 149468

over the catch information. The catch information is now tacked to the invoke
instruction.

llvm-svn: 149326

to 64-bits, and added a new attribute in bit #32. Specifically, remove
this new attribute from the enum used in the C API. It's not yet clear
what the best approach is for exposing these new attributes in the
C API, and several different proposals are on the table. Until then, we
can simply not expose this bit in the API at all.

Also, I've reverted a somewhat unrelated change in the same revision
which switched from "1 << 31" to "1U << 31" for the top enum. While "1
<< 31" is technically undefined behavior, implementations DTRT here.
However, MS and -pedantic mode warn about non-'int' type enumerator
values. If folks feel strongly about this I can put the 'U' back in, but
it seemed best to wait for the proper solution.

llvm-svn: 148937

llvm-svn: 148555

Problem: LLVM needs more function attributes than currently available (32 bits).
One such proposed attribute is "address_safety", which shows that a function is being checked for address safety (by AddressSanitizer, SAFECode, etc).

Solution:
- extend the Attributes from 32 bits to 64-bits
- wrap the object into a class so that unsigned is never erroneously used instead
- change "unsigned" to "Attributes" throughout the code, including one place in clang.
- the class has no "operator uint64 ()", but it has "uint64_t Raw() " to support packing/unpacking.
- the class has "safe operator bool()" to support the common idiom:  if (Attributes attr = getAttrs()) useAttrs(attr);
- The CTOR from uint64_t is marked explicit, so I had to add a few explicit CTOR calls
- Add the new attribute "address_safety". Doing it in the same commit to check that attributes beyond first 32 bits actually work.
- Some of the functions from the Attribute namespace are worth moving inside the class, but I'd prefer to have it as a separate commit.

Tested:
"make check" on Linux (32-bit and 64-bit) and Mac (10.6)
built/run spec CPU 2006 on Linux with clang -O2.


This change will break clang build in lib/CodeGen/CGCall.cpp.
The following patch will fix it.

llvm-svn: 148553

Patch by Andrew Wilkins!

llvm-svn: 146984

"half precision" floating-point with a first-class type.

This patch adds basic IR support (but not codegen support).

llvm-svn: 146786

- getSymbolOffset() renamed as getSymbolFileOffset()
- getSymbolFileOffset(), getSymbolAddress(), getRelocationAddress() returns same result for ELFObjectFile, MachOObjectFile and COFFObjectFile.
- added getRelocationOffset()
- fixed MachOObjectFile::getSymbolSize()
- fixed MachOObjectFile::getSymbolSection()
- fixed MachOObjectFile::getSymbolOffset() for symbols without section data.

llvm-svn: 145408