ambiguous term 'legal'.

Suggested by Andrew Booker. Thanks Andrew!

llvm-svn: 172680

Reported on IRC by _savage

llvm-svn: 172677

llvm-svn: 172670

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

llvm-svn: 172656

llvm-svn: 172655

llvm-svn: 172652

llvm-svn: 172651

llvm-svn: 172646

Patch by Jakub Staszak.

llvm-svn: 172645

llvm-svn: 172644

llvm-svn: 172642

llvm-svn: 172640

llvm-svn: 172638

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

llvm-svn: 172637

 - 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

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

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

llvm-svn: 172622

llvm-svn: 172615

llvm-svn: 172614

llvm-svn: 172612

Should fix the arm buildbot (which only builds the arm target).

llvm-svn: 172611

ASan: wrap mapping scale and offset in a struct and make it a member of ASan passes. Add test for non-default mapping scale and offset. No functionality change

llvm-svn: 172610

Without a triple opt falls back to NoTTI which comes closer to LSR's pre-TTI behavior.

llvm-svn: 172609

[ObjCARC] Turn off ignoring unwind edges in ObjCARC when -fno-objc-arc-exception is enabled due to it's affect on correctness.

Specifically according to the semantics of ARC -fno-objc-arc-exception simply
states that it is expected that the unwind path out of a call *MAY* not release
objects. Thus we can have the situation where a release gets moved into a catch
block which we ignore when we remove a retain/release pair resulting in (even
though we assume the program is exiting anyways) the cleanup code path
potentially blowing up before program exit.

llvm-svn: 172599

llvm-svn: 172594

of a class. Emit static data member declarations and definitions
through correctly.

Part of PR14471.

Patch by Paul Robinson!

llvm-svn: 172590

Since we already have this type it's a shame to keep dragging a pair of object
and method around explicitly.

llvm-svn: 172584

Use --enable-werror during configure time rather than
--with-extra-options.  This is cleaner and easier to read.

llvm-svn: 172581

llvm-svn: 172580

Hope you are feeling better.

The Mips RDHWR (Read Hardware Register) instruction was not 
tested for assembler or dissassembler consumption. This patch
adds that functionality.

Contributer: Vladimir Medic
 
llvm-svn: 172579

using the DW_FORM_GNU_addr_index and a separate .debug_addr section which
stays in the executable and is fully linked.

Sneak in two other small changes:

a) Print out the debug_str_offsets.dwo section.
b) Change form we're expecting the entries in the debug_str_offsets.dwo
   section to take from ULEB128 to U32.

Add tests for all of this in the fission-cu.ll test.

llvm-svn: 172578

Avoid a compiler warning about comparing disjoint enums but casting
them to int first.

llvm-svn: 172577

llvm-svn: 172576

into which we can emit single instructions without fixups (which is most
instructions). This is an optimization required because MCDataFragment
is prety large (240 bytes on x64), with no change in functionality.

For large programs, this reduces memory usage overhead required for bundling
by 40%.

To make the code as palatable as possible, the MCEncodedFragment interface was
further fragmented (no pun intended) and MCEncodedFragmentWithFixups is used
as the interface to work against when the user expects fixups. MCDataFragment
and MCRelaxableFragment implement this interface, while the new
MCCompactEncodedInstFragment implements MCEncodeFragment.

llvm-svn: 172572

// FIXME: Constraints are hard coded to 'm', but we need an 'r'
// constraint for addressof.  This needs to be cleaned up!

Test cases are already in place.  Specifically,
clang/test/CodeGen/ms-inline-asm.c t15(), t16(), and t24().

llvm-svn: 172569

After discussing the refactoring with Jim and Daniel, the following changes were
made:

* All generic directive parsing is now done by AsmParser itself. The previous
  division between it and GenericAsmParser did not have clear boundaries and
  just produced unnatural code of GenericAsmParser juggling the internals of
  AsmParser through an interface. 
  The division of responsibilities is now clear: target-specific directives,
  other extensions (used by platform-specific parseres), and generic directives.
* Priority for directive parsing was reshuffled to ask extensions first and
  check the generic directives later.

No change in functionality.

llvm-svn: 172568

llvm-svn: 172556