llvm-svn: 189315

Right now we have two headers for the Mach-O format. I'd like to get rid
of one. Since the other object formats are all in Support, I chose to
keep the Mach-O header in Support, and discard the other one.

llvm-svn: 189314

should not split up that pathname itself or require quoting to avoid the same.

This fixing a bug where target create -c "core file" or target create -s "symbol file"
will fail with an error message that the paths haven't been properly quoted.  Working
around it required target create -c "core\ file" to survive both attemps at tokenizing.

<rdar://problem/14230629> 

llvm-svn: 189313

Noticed by Stephen Checkoway <s@pahtak.org>.

llvm-svn: 189312

Patch by Edoardo P. <ed0.88.prez@gmail.com>.

llvm-svn: 189311

llvm-svn: 189310

The code offset for unwind code SET_FPREG is wrong because it is set
to constant 0. The fix is to do the same as for the other unwind
codes: emit a label and later the absolute difference between the
label and the begin of the prologue.
Also enables the failing test case MC/COFF/seh.s

Reviewed by Jim Grosbach, Charles Davis and Nico Rieck.

llvm-svn: 189309

llvm-svn: 189308

With this patch the entry symbol is treated as an undefined symbol, to force
the resolver to resolve the entry symbol.

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

llvm-svn: 189307

llvm-svn: 189306

out of a binary, if the Mach-O binary is MH_PRELOAD ("standalone"), don't
let the OS be set to "ios" or "macosx" - there will be no dynamic loader
used when debugging this process.
<rdar://problem/9956443> 

llvm-svn: 189305

This sets flags and excludes things that aren't working with MSVC yet,
allowing us to build the ASan runtime as part of the cmake build.

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

llvm-svn: 189304

latest draft of the ABI.

llvm-svn: 189303

llvm-svn: 189302

llvm-svn: 189301

off of the debug_info section even when split dwarf is enabled.

llvm-svn: 189300

Remove an over-zealous assertion.  A pointer type could be illegal if the target is prepared to custom-legalize pointer operands.  This assertion was evaluated before the target would have a chance to do so, making it impossible.

llvm-svn: 189299

This should have been done in r187823 when I renamed LinkingContext
from TargetInfo. I missed a few files.

llvm-svn: 189298

  This API is proposed by Nick Kledzik. The semantic is:

  --------------------------------------------------------------------------
   Generate code for merged module into an array of native object files. On 
   success returns a pointer to an array of NativeObjectFile.  The count 
   parameter returns the number of elements in the array.  Each element is 
   a pointer/length for a generated mach-o/ELF buffer.  The buffer is owned
   by the lto_code_gen_t and will be freed when lto_codegen_dispose() is called, 
   or lto_codegen_compile() is called again. On failure, returns NULL 
   (check lto_get_error_message() for details).

   extern const struct  NativeObjectFile*
   lto_codegen_compile_parallel(lto_code_gen_t cg, size_t *count);
  ---------------------------------------------------------------------------

  This API is currently only called on OSX platform. Linux or other Unixes
using GNU gold are not supposed to call this function, because on these systems, 
object files are fed back to linker via disk file instead of memory buffer.

  In this commit, lto_codegen_compile_parallel() simply calls
lto_codegen_compile() to return a single object file. In the near future,
this function is the entry point for compilation with partition. Linker can
blindly call this function even if partition is turned off; in this case,
compiler will return only one object file.

llvm-svn: 189297

llvm-svn: 189296

    Summary:
    This merge brings in the improved 'platform' command that knows how to
    interface with remote machines; that is, query OS/kernel information, push
    and pull files, run shell commands, etc... and implementation for the new
    communication packets that back that interface, at least on Darwin based
    operating systems via the POSIXPlatform class. Linux support is coming soon.

    Verified the test suite runs cleanly on Linux (x86_64), build OK on Mac OS
    X Mountain Lion.

    Additional improvements (not in the source SVN branch 'lldb-platform-work'):
    - cmake build scripts for lldb-platform
    - cleanup test suite
    - documentation stub for qPlatform_RunCommand
    - use log class instead of printf() directly
    - reverted work-in-progress-looking changes from test/types/TestAbstract.py that work towards running the test suite remotely.
    - add new logging category 'platform'

    Reviewers: Matt Kopec, Greg Clayton

    Review: http://llvm-reviews.chandlerc.com/D1493

llvm-svn: 189295

MDNode more clear as just for a single argument.

llvm-svn: 189294

is constructing from as an input and keep the same unique identifier.
We can use this to connect items which must stay in the .o file
(e.g. pubnames and pubtypes) to the skeleton cu rather than having
duplicate unique numbers for the sections and needing to do lookups
based on MDNode.

llvm-svn: 189293

llvm-svn: 189292

can get it via the MDNode that's passed in. Save that instead.

llvm-svn: 189291

llvm-svn: 189290

it by default under linux or when we're trying to keep compatibility
with old gdb versions.

Fix testcase for option name change.

llvm-svn: 189289

llvm-svn: 189288

This follows from computeKeyFunction having:

  // Template instantiations don't have key functions,see Itanium C++ ABI 5.2.6.
  // Same behavior as GCC.
  TemplateSpecializationKind TSK = RD->getTemplateSpecializationKind();
  if (TSK == TSK_ImplicitInstantiation ||
      TSK == TSK_ExplicitInstantiationDefinition)
    return 0;

llvm-svn: 189287

Thanks David for his suggestion. This commit updates testing cases
to have more specific CHECKs.

llvm-svn: 189286

The builder inserts from before the insert point,
not after, so this would insert before the last
instruction in the bundle instead of after it.

I'm not sure if this can actually be a problem
with any of the current insertions.

llvm-svn: 189285

Since r179585, __declspec(property) has gotten special treatment as an attribute where it is not processed as part of the typical Sema attribute functionality.  Specifying this attribute as being "ignored" because there is no sema handler for it as a Decl attribute, and no AST node generated for it.

llvm-svn: 189284

Paired with llvm r189282.
Update testing cases to handle an extra field for DICompositeType.

llvm-svn: 189283

DICompositeType will have an identifier field at position 14. For now, the
field is set to null in DIBuilder.
For DICompositeTypes where the template argument field (the 13th field)
was optional, modify DIBuilder to make sure the template argument field is set.
Now DICompositeType has 15 fields.

Update DIBuilder to use NULL instead of "i32 0" for null value of a MDNode.
Update verifier to check that DICompositeType has 15 fields and the last
field is null or a MDString.

Update testing cases to include an extra field for DICompositeType.
The identifier field will be used by type uniquing so a front end can
genearte a DICompositeType with a unique identifer.

llvm-svn: 189282

This patch enables unrolling of loops when vectorization is legal but not profitable.
We add a new class InnerLoopUnroller, that extends InnerLoopVectorizer and replaces some of the vector-specific logic with scalars.

This patch does not introduce any runtime regressions and improves the following workloads:

SingleSource/Benchmarks/Shootout/matrix -22.64%
SingleSource/Benchmarks/Shootout-C++/matrix -13.06%
External/SPEC/CINT2006/464_h264ref/464_h264ref  -3.99%
SingleSource/Benchmarks/Adobe-C++/simple_types_constant_folding -1.95%

llvm-svn: 189281

llvm-svn: 189280

llvm-svn: 189279

The change was made for readability, as the PropagationInfo objects don't
always contain a status.  This is submitted as a separate patch because it
touches a lot of lines and I don't want it cluttering up the next patch.
Patch by chris.wailes@gmail.com.

llvm-svn: 189278

CodeGenFunction is run on only one function - a new object is made for
each new function. I would add an assertion/flag to this effect, but
there's an exception: ObjC properties involve emitting helper functions
that are all emitted by the same CodeGenFunction object, so such a check
is not possible/correct.

llvm-svn: 189277

llvm-svn: 189276