Apparently this makes my email address easier to find.

llvm-svn: 262951

Add a missing include.  This is important in the case HandleLLVMOptions is
included prior to the missing CheckCXXSourceCompiles or CheckCXXCompilerFlag
which includes CheckCXXSourceCompiles.

llvm-svn: 262949

This adds llvm_add_implicit_projects which takes a project name and is wrapped by add_llvm_implicit_projects.

llvm-svn: 262948

llvm-svn: 262944

The fix consisting in using the library call for atomic compare and swap when
the instruction is not safe to use may be incorrect. Indeed the library call may
not exist on all platform. In other words, we need a better fix! 

llvm-svn: 262943

Test to be committed in follow up commit, per discussion in D17097.
http://reviews.llvm.org/D17097

llvm-svn: 262942

llvm-svn: 262940

This was inadvertently omitted from r262774, which added the mutation
interface.

llvm-svn: 262939

llvm-svn: 262937

Reviewers: t.p.northover, grosbach, resistor

Subscribers: aemerson, rengolin, llvm-commits

Differential Revision: http://reviews.llvm.org/D17636

llvm-svn: 262936

This caused PR26870.

llvm-svn: 262935

llvm-svn: 262934

llvm-svn: 262930

Differential Revision: http://reviews.llvm.org/D17953

llvm-svn: 262929

llvm-svn: 262926

Summary: I left --build-system for backwards compat, in case there are scripts using it. Feel free to ask for its removal too.

Reviewers: chapuni, tstellarAMD

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D17886

llvm-svn: 262924

llvm-svn: 262919

This commit removes pr25342 for reverting r262670 clearly.

llvm-svn: 262918

This reverts commit r262670 due to compile failure.

llvm-svn: 262916

Should fix the breakage in r262902.

llvm-svn: 262908

llvm-svn: 262907

We follow the comments mentioned in http://reviews.llvm.org/D16842#344378 to
implement this new patch.

This patch implements the following vsx instructions:

Vector load/store:
lxv lxvx lxvb16x lxvl lxvll lxvh8x lxvwsx
stxv stxvb16x stxvh8x stxvl stxvll stxvx
Scalar load/store:
lxsd lxssp lxsibzx lxsihzx
stxsd stxssp stxsibx stxsihx
21 instructions

Phabricator: http://reviews.llvm.org/D16919
llvm-svn: 262906

Also note that the operand order changed; the default label is now listed
after the regular labels.

llvm-svn: 262903

This re-applies r262886 with a fix for 32 bit platforms that have 8 byte
pointer alignment, effectively reverting r262892.

Original Message:

  Currently some SDNode operands are malloc'd, some are stored inline in
  subclasses of SDNode, and some are thrown into a BumpPtrAllocator.
  This scheme is complex, inconsistent, and makes refactoring SDNodes
  fairly difficult.

  Instead, we can allocate all of the operands using an ArrayRecycler
  that wraps a BumpPtrAllocator. This keeps the cache locality when
  iterating operands, improves locality when iterating SDNodes without
  looking at operands, and vastly simplifies the ownership semantics.

  It also means we stop overallocating SDNodes by 2-3x and will make it
  simpler to fix the rampant undefined behaviour we have in how we
  mutate SDNodes from one kind to another (See llvm.org/pr26808).

  This is NFC other than the changes in memory behaviour, and I ran some
  LNT tests to make sure this didn't hurt compile time. Not many tests
  changed: there were a couple of 1-2% regressions reported, but there
  were more improvements (of up to 4%) than regressions.

llvm-svn: 262902

Thanks to Ahmed Bougacha for noticing!

llvm-svn: 262899

llvm-svn: 262898

llvm-svn: 262897

llvm-svn: 262896

llvm-svn: 262893

Looks like the largest SDNode is different between 32 and 64 bit now,
so this is breaking 32 bit bots. Reverting while I figure out a fix.

This reverts r262886.

llvm-svn: 262892

llvm-svn: 262891

By complex types, I mean aggregate or vector types.

llvm-svn: 262890

Currently some SDNode operands are malloc'd, some are stored inline in
subclasses of SDNode, and some are thrown into a BumpPtrAllocator.
This scheme is complex, inconsistent, and makes refactoring SDNodes
fairly difficult.

Instead, we can allocate all of the operands using an ArrayRecycler
that wraps a BumpPtrAllocator. This keeps the cache locality when
iterating operands, improves locality when iterating SDNodes without
looking at operands, and vastly simplifies the ownership semantics.

It also means we stop overallocating SDNodes by 2-3x and will make it
simpler to fix the rampant undefined behaviour we have in how we
mutate SDNodes from one kind to another (See llvm.org/pr26808).

This is NFC other than the changes in memory behaviour, and I ran some
LNT tests to make sure this didn't hurt compile time. Not many tests
changed: there were a couple of 1-2% regressions reported, but there
were more improvements (of up to 4%) than regressions.

llvm-svn: 262886

Before this change, we would get the type definition in the middle
of the instruction.
E.g., %0(48) = G_ADD %struct_alias = type { i32, i16 } %edi, %edi

Now, we have just the expected type name:
%0(48) = G_ADD %struct_alias %edi, %edi

llvm-svn: 262885

Without actually parsing a type it is difficult to perdict where
the type definition ends. In other words, instead of expecting
the user of the parser API to hand over only the relevant bits
of the string being parsed, take the whole string, parse the type,
and get back the number of characters that have been read.

This will be used by the MIR testing infrastructure.

llvm-svn: 262884

llvm-svn: 262883

llvm-svn: 262880

llvm-svn: 262879

llvm-svn: 262878

llvm-config can know tell whether or not a build has been configured to support
global-isel.
Use '--has-global-isel' for that.

llvm-svn: 262877