llvm-svn: 133449

Use the dyld_mode, image_infos & image_infos_count passed into the shared library notification function
to update libraries rather than reading the whole all_imaage_infos structure every time we get notified.

llvm-svn: 133448

llvm-svn: 133447

llvm-svn: 133446

The current implementation generates stack loads/stores, which are
really just mov instructions from/to "special" registers.  This may
not be the most efficient implementation, compared to an approach where
the stack registers are directly folded into instructions, but this is
easier to implement and I have yet to see a case where ptxas is unable
to see through this kind of register usage and know what is really
going on.

llvm-svn: 133443

with 32bit values.

llvm-svn: 133439

llvm-svn: 133438

llvm-svn: 133437

point during the development of the phi operand changes.

llvm-svn: 133436

Change PHINodes to store simple pointers to their incoming basic blocks,
instead of full-blown Uses.

Note that this loses an optimization in SplitCriticalEdge(), because we
can no longer walk the use list of a BasicBlock to find phi nodes. See
the comment I removed starting "However, the foreach loop is slow for
blocks with lots of predecessors".

Extend replaceAllUsesWith() on a BasicBlock to also update any phi
nodes in the block's successors. This mimics what would have happened
when PHINodes were proper Users of their incoming blocks. (Note that
this only works if OldBB->replaceAllUsesWith(NewBB) is called when
OldBB still has a terminator instruction, so it still has some
successors.)

llvm-svn: 133435

Change various bits of code to make better use of the existing PHINode
API, to insulate them from forthcoming changes in how PHINodes store
their operands.

llvm-svn: 133434

I don't think the AugmentedUse struct buys us much, either in
correctness or in ease of use. Ditch it, and simplify Use::getUser() and
User::allocHungoffUses().

llvm-svn: 133433

* Don't introduce a duplicated bb in the CFG
* When making a branch unconditional, clear the PredCond array so that it
  is really unconditional.

llvm-svn: 133432

dragonegg buildbots back to life.  Original commit message:
Teach early dup how to duplicate basic blocks with one successor and only phi instructions
into more complex blocks.

llvm-svn: 133430

types printed in various diagnostics.

We could omit checking for the types, but that can mask errors where the
wrong type is streamed into the diagnostic. There was at least one of
these caught by this test already.

llvm-svn: 133429

pointers I found while working on the NULL arithmetic warning. We here
always assuming the LHS was the pointer, instead of using the selected
pointer expression.

llvm-svn: 133428

llvm-svn: 133426

effectively that this abstraction simply doesn't exist. That is
highlighted by the fact that by using it we were papering over a more
serious error in this warning: the fact that we warned for *invalid*
constructs involving member pointers and block pointers.

I've fixed the obvious issues with the warning here, but this is
confirming an original suspicion that this warning's implementation is
flawed. I'm looking into how we can implement this more reasonably. WIP
on that front.

llvm-svn: 133425

source vector type is to be split while the target vector is to be promoted.
(eg: <4 x i64> -> <4 x i8> )

llvm-svn: 133424

llvm-svn: 133418

llvm-svn: 133417

Fix MSVC build. next() function already exists in the MSVC headers. This create a overload conflict. Make sure we pick up the llvm one.

llvm-svn: 133416

into more complex blocks.

llvm-svn: 133415

ConvertType on InitListExprs as they are being converted.  This is
needed for a forthcoming patch, and improves the IR generated anyway
(see additional type names in testcases). 

This patch also converts a bunch of std::vector's in CGObjCMac to use
C arrays.  There are a ton more that should be converted as well.

llvm-svn: 133413

all over the place in different styles and variants.  Standardize on two
preferred entrypoints: one that takes a StructType and ArrayRef, and one that
takes StructType and varargs.

In cases where there isn't a struct type convenient, we now add a
ConstantStruct::getAnon method (whose name will make more sense after a few
more patches land).  

It would be "really really nice" if the ConstantStruct::get and 
ConstantVector::get methods didn't make temporary std::vectors.

llvm-svn: 133412

llvm-svn: 133410

equality check.

llvm-svn: 133409

[analyzer] Re-enable checking for strncpy, along with a new validation of the size argument. strncat is not yet up-to-date, but I'm leaving it enabled for now (there shouldn't be any false positives, at least...)

llvm-svn: 133408

A RegisterTuples instance is used to synthesize super-registers by
zipping together lists of sub-registers. This is useful for generating
pseudo-registers representing register sequence constraints like 'two
consecutive GPRs', or 'an even-odd pair of floating point registers'.

The RegisterTuples def can be used in register set operations when
building register classes. That is the only way of accessing the
synthesized super-registers.

For example, the ARM QQ register class of pseudo-registers could have
been formed like this:

  // Form pairs Q0_Q1, Q2_Q3, ...
  def QQPairs : RegisterTuples<[qsub_0, qsub_1],
                               [(decimate QPR, 2),
                                (decimate (shl QPR, 1), 2)]>;

  def QQ : RegisterClass<..., (add QQPairs)>;

Similarly, pseudo-registers representing '3 consecutive D-regs with
wraparound' look like:

  // Form D0_D1_D2, D1_D2_D3, ..., D30_D31_D0, D31_D0_D1.
  def DSeqTriples : RegisterTuples<[dsub_0, dsub_1, dsub_2],
                                   [(rotl DPR, 0),
                                    (rotl DPR, 1),
                                    (rotl DPR, 2)]>;

TableGen automatically computes aliasing information for the synthesized
registers.

Register tuples are still somewhat experimental. We still need to see
how they interact with MC.

llvm-svn: 133407

[analyzer] Eliminate "byte string function" from CStringChecker's diagnostics, and make it easier to provide custom messages for overflow checking, in preparation for re-enabling strncpy checking.

llvm-svn: 133406

This makes 'isPointerLikeType' a little less confusing, and pulls the
decay check into a separate interface that is much more clear and
concrete. Also, just implement these as logical wrappers around other
predicates. Having a switch based implementation isn't likely to be
necessary. We can try to optimize them later if they show up on
a profile.

llvm-svn: 133405

Add TestInlinedFrame.py to exercise the newly added SBFrame APIs: IsInlined() and GetFunctionName().

llvm-svn: 133404

More fixes:  One of my fixes to type_traits earlier today was incorrect, so that is reverted.  Recently clang appears to have tightened up its definition of is_convertible and that has caused some failures in [unordered_][multi]map.  I've switched to using is_constructible to restablish the desired functionality in [unordered_][multi]map.  Specifically, inserting rvalues of move-only types for the keys.

llvm-svn: 133402

llvm-svn: 133401

const Constant *.

llvm-svn: 133400

llvm-svn: 133390

llvm-svn: 133389

llvm-svn: 133388

llvm-svn: 133387

llvm-svn: 133386