llvm-svn: 172659

Moving the X86CostTable to a common place, so that other back-ends
can share the code. Also simplifying it a bit and commoning up
tables with one and two types on operations.

llvm-svn: 172658

    
Instead of writing the result of each transform to disk for every
transform, write the results to buffers in memory and pass those buffers
to the next transform as input. Only write the buffers to disk if the
final syntax check passes.

Reviewers: klimek
llvm-svn: 172657

llvm-svn: 172656

llvm-svn: 172655

I think the main issue was the lack of -ffreestanding, which pulled in
the host's stdint.h. After that things went rapidly downhill.

llvm-svn: 172653

llvm-svn: 172652

llvm-svn: 172651

llvm-svn: 172650

initializations to fix Wreorder warning.

llvm-svn: 172649

llvm-svn: 172648

llvm-svn: 172647

llvm-svn: 172646

Patch by Jakub Staszak.

llvm-svn: 172645

llvm-svn: 172644

Adding verbiage to the Language Extensions document about __has_include and __has_include_next only being allowed within preprocessor directives.

llvm-svn: 172643

llvm-svn: 172642

llvm-svn: 172641

llvm-svn: 172640

No longer crashing with an assert when __has_include or __has_include_next is used outside of a preprocessor directive.  This fixes PR14837.

llvm-svn: 172639

llvm-svn: 172638

return into the safe harbor of AsmParser's private areas.

llvm-svn: 172637

Adding FindFirstGlobalVariable to SBModule and SBTarget
These calls work like FindGlobalVariables but they only return the first match found and so they can return an SBValue instead of an SBValueList for added convenience of use

llvm-svn: 172636

when the methods are declared in a submodule that has not yet been
imported. Part of <rdar://problem/10634711>. 

llvm-svn: 172635

 - Instead of computing a bunch of buckets of different flag types, just do an
   incremental link resolving conflicts as they arise.

 - This also has the advantage of making the link result deterministic and not
   dependent on map iteration order.

llvm-svn: 172634

Greg created a new API on SBProcess to get an ID that is guaranteed to be unique even in situations where underlying platforms would actually duplicate or hardcode PIDs

The Python data formatters use a per-process cache that was previously keying off the PID. Moving that to be based on this new notion of unique ID.

llvm-svn: 172633

null before using it.

llvm-svn: 172632

Make a few tests optimization-proof.  These tests were failing under -O3 because the optimizer was eliminating the call to new.

llvm-svn: 172631

AT_producer.  Which includes clang's version information so we can tell
which version of the compiler was used.

This is the first of two steps to allow us to do that.  This is the llvm-mc
change to provide a method to set the AT_producer string.  The second step,
coming soon to a clang near you, will have the clang driver pass the value
of getClangFullVersion() via an flag when invoking the integrated assembler
on assembly source files.

rdar://12955296

llvm-svn: 172630

while deserializing a macro, make sure to copy/move what we need from it.

Fixes clang-x86_64-debian-fast bot.

llvm-svn: 172629

Added a unique integer identifier to processes. Some systems, like JTAG or other simulators, might always assign the same process ID (pid) to the processes that are being debugged. In order for scripts and the APIs to uniquely identify the processes, there needs to be another ID. Now the SBProcess class has:

uint32_t SBProcess::GetUniqueID();

This integer ID will help to truly uniquely identify a process and help with appropriate caching that can be associated with a SBProcess object.

llvm-svn: 172628

In r143502, we renamed getHostTriple() to getDefaultTargetTriple()
as part of work to allow the user to supply a different default
target triple at configure time.  This change also affected the JIT.
However, it is inappropriate to use the default target triple in the
JIT in most circumstances because this will not necessarily match
the current architecture used by the process, leading to illegal
instruction and other such errors at run time.

Introduce the getProcessTriple() function for use in the JIT and
its clients, and cause the JIT to use it.  On architectures with a
single bitness, the host and process triples are identical.  On other
architectures, the host triple represents the architecture of the
host CPU, while the process triple represents the architecture used
by the host CPU to interpret machine code within the current process.
For example, when executing 32-bit code on a 64-bit Linux machine,
the host triple may be 'x86_64-unknown-linux-gnu', while the process
triple may be 'i386-unknown-linux-gnu'.

This fixes JIT for the 32-on-64-bit (and vice versa) build on non-Apple
platforms.

Differential Revision: http://llvm-reviews.chandlerc.com/D254

llvm-svn: 172627

Waiting for new llvm attribute code for the next step.

llvm-svn: 172626

set on the cursor; return a null type in such a case.

llvm-svn: 172625

Before: Constructor() : a(a), // comment a(a) {}
After:  Constructor() : a(a), // comment
                        a(a) {}

Needed this as a quick fix. Will add more tests for this in a future
commit.

llvm-svn: 172624

Patch by Enea Zaffanella!

llvm-svn: 172623

llvm-svn: 172622

We used to incorrectly parse

aaaaaa ? aaaaaa(aaaaaa) : aaaaaaaa;

Due to an l_paren being followed by a colon, we assumed it to be part of
a constructor initializer. Thus, we never found the colon belonging to
the conditional expression, marked the line as bing incorrect and did
not format it.

llvm-svn: 172621

Previously we would serialize the macro redefinitions as a list, part of
the identifier, and try to chain them together across modules individually
without having the info that they were already chained at definition time.

Change this by serializing the macro redefinition chain and then try
to synthesize the chain parts across modules. This allows us to correctly
pinpoint when 2 different definitions are ambiguous because they came from
unrelated modules.

Fixes bogus "ambiguous expansion of macro" warning when a macro in a PCH
is redefined without undef'ing it first.

rdar://13016031

llvm-svn: 172620

Before: int x = ** a;
After:  int x = **a;
llvm-svn: 172619