The LLVM diagnostic are now wired-up in clang (since r200931),
thus the user experience will not be impacted by this change
anymore.

Related to <rdar://problem/15886697>

llvm-svn: 201915

This reapplies r197438 and fixes the link-time circular dependency between
IR and Support. The fix consists in moving the diagnostic support into IR.

The patch adds a new LLVMContext::diagnose that can be used to communicate to
the front-end, if any, that something of interest happened.
The diagnostics are supported by a new abstraction, the DiagnosticInfo class.
The base class contains the following information:
- The kind of the report: What this is about.
- The severity of the report: How bad this is.

This patch also adds 2 classes:
- DiagnosticInfoInlineAsm: For inline asm reporting. Basically, this diagnostic
will be used to switch to the new diagnostic API for LLVMContext::emitError.
- DiagnosticStackSize: For stack size reporting. Comes as a replacement of the
hard coded warning in PEI.

This patch also features dynamic diagnostic identifiers. In other words plugins
can use this infrastructure for their own diagnostics (for more details, see
getNextAvailablePluginDiagnosticKind).

This patch introduces a new DiagnosticHandlerTy and a new DiagnosticContext in
the LLVMContext that should be set by the front-end to be able to map these
diagnostics in its own system.

http://llvm-reviews.chandlerc.com/D2376
<rdar://problem/15515174>

llvm-svn: 197508

llvm-svn: 197451

The patch adds a new LLVMContext::diagnose that can be used to communicate to
the front-end, if any, that something of interest happened.
The diagnostics are supported by a new abstraction, the DiagnosticInfo class.
The base class contains the following information:
- The kind of the report: What this is about.
- The severity of the report: How bad this is.

This patch also adds 2 classes:
- DiagnosticInfoInlineAsm: For inline asm reporting. Basically, this diagnostic
will be used to switch to the new diagnostic API for LLVMContext::emitError.
- DiagnosticStackSize: For stack size reporting. Comes as a replacement of the
hard coded warning in PEI.

This patch also features dynamic diagnostic identifiers. In other words plugins
can use this infrastructure for their own diagnostics (for more details, see
getNextAvailablePluginDiagnosticKind).

This patch introduces a new DiagnosticHandlerTy and a new DiagnosticContext in
the LLVMContext that should be set by the front-end to be able to map these
diagnostics in its own system.

http://llvm-reviews.chandlerc.com/D2376
<rdar://problem/15515174>

llvm-svn: 197438

The "invariant.load" metadata indicates the memory unit being accessed is immutable.
A load annotated with this metadata can be moved across any store.

As I am not sure if it is legal to move such loads across barrier/fence, this
change dose not allow such transformation.

rdar://11311484

Thank Arnold for code review.

llvm-svn: 176562

Add static cast to unsigned char whenever a character classification function is called with a signed char argument, in order to avoid assertions in Windows Debug configuration.

llvm-svn: 175006

This reverts my commit 171047. Now that I've removed my misguided attempt to
support backend warnings, these diagnostics are only about inline assembly.
It would take quite a bit more work to generalize them properly, so I'm
just reverting this.

llvm-svn: 174860

This reverts r171041. This was a nice idea that didn't work out well.
Clang warnings need to be associated with warning groups so that they can
be selectively disabled, promoted to errors, etc. This simplistic patch didn't
allow for that. Enhancing it to provide some way for the backend to specify
a front-end warning type seems like overkill for the few uses of this, at
least for now.

llvm-svn: 174748

into their new header subdirectory: include/llvm/IR. This matches the
directory structure of lib, and begins to correct a long standing point
of file layout clutter in LLVM.

There are still more header files to move here, but I wanted to handle
them in separate commits to make tracking what files make sense at each
layer easier.

The only really questionable files here are the target intrinsic
tablegen files. But that's a battle I'd rather not fight today.

I've updated both CMake and Makefile build systems (I think, and my
tests think, but I may have missed something).

I've also re-sorted the includes throughout the project. I'll be
committing updates to Clang, DragonEgg, and Polly momentarily.

llvm-svn: 171366

Aside from moving the actual files, this patch only updates the build
system and the source file comments under lib/... that are relevant.

I'll be updating other docs and other files in smaller subsequnet
commits.

While I've tried to test this, but it is entirely possible that there
will still be some build system fallout.

Also, note that I've not changed the library name itself: libLLVMCore.a
is still the library name. I'd be interested in others' opinions about
whether we should rename this as well (I think we should, just not sure
what it might break)

llvm-svn: 171359

llvm-svn: 171120

These are now generally used for all diagnostics from the backend, not just
for inline assembly, so this drops the "InlineAsm" from the names.  No
functional change.  (I've left aliases for the old names but only for long
enough to let me switch over clang to use the new ones.)

llvm-svn: 171047

When the backend is used from clang, it should produce proper diagnostics
instead of just printing messages to errs(). Other clients may also want to
register their own error handlers with the LLVMContext, and the same handler
should work for warnings in the same way as the existing emitError methods.

llvm-svn: 171041

Sooooo many of these had incorrect or strange main module includes.
I have manually inspected all of these, and fixed the main module
include to be the nearest plausible thing I could find. If you own or
care about any of these source files, I encourage you to take some time
and check that these edits were sensible. I can't have broken anything
(I strictly added headers, and reordered them, never removed), but they
may not be the headers you'd really like to identify as containing the
API being implemented.

Many forward declarations and missing includes were added to a header
files to allow them to parse cleanly when included first. The main
module rule does in fact have its merits. =]

llvm-svn: 169131

llvm-svn: 163815

revert r158660, since Chris has some issues with this patch (namely using code to reprent information only used by the compiler)

Original commit msg:
add the 'alloc' metadata node to represent the size of offset of buffers pointed to by pointers.
This metadata can be attached to any instruction returning a pointer

llvm-svn: 158688

This metadata can be attached to any instruction returning a pointer

llvm-svn: 158660

thinking of generalizing it to be able to specify other freedoms beyond accuracy
(such as that NaN's don't have to be respected).  I'd like the 3.1 release (the
first one with this metadata) to have the more generic name already rather than
having to auto-upgrade it in 3.2.

llvm-svn: 154744

metadata.

llvm-svn: 153359

llvm-svn: 147501

llvm-svn: 143135

string, pass it around as an enum.

llvm-svn: 142107

llvm-svn: 134516

llvm-svn: 122193

headers provide symbols outside namespace std and the LLVM coding standards
state that we should prefix all of them.

llvm-svn: 122192

llvm-svn: 122099

cookie argument to the SourceMgr diagnostic stuff.  This cleanly separates
LLVMContext's inlineasm handler from the sourcemgr error handling 
definition, increasing type safety and cleaning things up.

llvm-svn: 119486

isn't a good level of abstraction for memdep. Instead, generalize
AliasAnalysis::alias and related interfaces with a new Location
class for describing a memory location. For now, this is the same
Pointer and Size as before, plus an additional field for a TBAA tag.

Also, introduce a fixed MD_tbaa metadata tag kind.

llvm-svn: 113858

modules are instantiated in them.  If the context is deleted, all of its owned
modules are also deleted.

llvm-svn: 113374

bitcode file, so that two bitcode files where the same metadata kind
name happens to have been assigned a different ID can still be
linked together.

Eliminate the restriction that metadata kind IDs can't be 0.

Change MD_dbg from 1 to 0, because we can now, and because it's
less mysterious that way.

llvm-svn: 108939

and use it in one place in inline asm handling stuff.  Before
we'd generate this for an invalid modifier letter:

$ clang asm.c -c -o t.o
fatal error: error in backend: Invalid operand found in inline asm: 'abc incl    ${0:Z}'
INLINEASM <es:abc incl    ${0:Z}>, 10, %EAX<def>, 2147483657, %EAX, 14, %EFLAGS<earlyclobber,def,dead>, <!-1>


Now we generate this:

$ clang asm.c -c -o t.o
error: invalid operand in inline asm: 'incl    ${0:Z}'
asm.c:3:12: note: generated from here
  __asm__ ("incl    %Z0" : "+r" (X));
           ^
1 error generated.

This is much better but still admittedly not great ("why" is the operand 
invalid??), codegen should try harder with its diagnostics :)

llvm-svn: 100723

llvm-svn: 100506

the storage of !dbg metadata kinds in the instruction themselves.
The on-the-side hash table works great for metadata that not-all
instructions get, or for metadata that only exists when optimizing.
But when compile-time is everything, it isn't great.

I'm not super thrilled with the fact that this plops a TrackingVH in
Instruction, because it grows it by 3 words.  I'm investigating 
alternatives, but this should be a step in the right direction in any
case.

llvm-svn: 99957

llvm-svn: 99927

getMDKindID/getMDKindNames methods to LLVMContext (and add
convenience methods to Module), eliminating MetadataContext.
Move the state that it maintains out to LLVMContext.

llvm-svn: 92259

llvm-svn: 92212

llvm-svn: 84801

llvm-svn: 83019

This interface will be used to attach metadata with an instruction.

llvm-svn: 82060

MDNode's operand list does not include all elements.

llvm-svn: 81045