llvm-svn: 175621

If the code author decides to put empty lines anywhere into the code we
should treat them equally, i.e. reduce them to the configured
MaxEmptyLinesToKeep.

With this change, we e.g. keep the newline in:
SomeType ST = {
  // First value
  a,

  // Second value
  b
};

llvm-svn: 175620

 sext <4 x i1> to <4 x i64>
 sext <4 x i8> to <4 x i64>
 sext <4 x i16> to <4 x i64>
 
I'm running Combine on SIGN_EXTEND_IN_REG and revert SEXT patterns:
 (sext_in_reg (v4i64 anyext (v4i32 x )), ExtraVT) -> (v4i64 sext (v4i32 sext_in_reg (v4i32 x , ExtraVT)))
 
 The sext_in_reg (v4i32 x) may be lowered to shl+sar operations.
 The "sar" does not exist on 64-bit operation, so lowering sext_in_reg (v4i64 x) has no vector solution.

I also added a cost of this operations to the AVX costs table.

llvm-svn: 175619

llvm-svn: 175618

llvm-svn: 175617

It is possible that frame pointer is not found in the
callee saved info, thus FramePtrSpillFI may be incorrect
if we don't check the result of hasFP(MF).

Besides, if we enable the stack coloring algorithm, there
will be an assertion to ensure the slot is live.  But in
the test case, %var1 is not live in the prologue of the
function, and we will get the assertion failure.

Note: There is similar code in ARMFrameLowering.cpp.
llvm-svn: 175616

llvm-svn: 175615

llvm-svn: 175614

An alternative strategy to calculating the break on demand when hitting
a token that would need to be broken would be to put all possible breaks
inside the token into the optimizer.

Currently only supports breaking at spaces; more break points to come.

llvm-svn: 175613

llvm-svn: 175610

llvm-svn: 175609

llvm-svn: 175608

llvm-svn: 175607

function attributes.

llvm-svn: 175606

This makes the LLVM assembly look better. E.g.:

     define void @foo() #0 { ret void }
     attributes #0 = { nounwind noinline ssp }

llvm-svn: 175605

common transformations. This includes updating repairIntervalsInRange() to
handle more cases.

llvm-svn: 175604

correct value is needed in every iteration of the loop for updating
LiveIntervals.

llvm-svn: 175603

llvm-svn: 175602

and removing instructions. The implementation seems more complicated than it
needs to be, but I couldn't find something simpler that dealt with all of the
corner cases.

Also add a call to repairIndexesInRange() from repairIntervalsInRange().

llvm-svn: 175601

llvm-svn: 175600

assertions in the register allocator when running 'make check' without
LiveVariables.

llvm-svn: 175599

after the two-address pass. The remaining problems in 'make check' are occurring
later.

llvm-svn: 175598

llvm-svn: 175597

llvm-svn: 175596

Code review feedback on r175580 from Jordan Rose.

llvm-svn: 175595

See r175462 for another example/more details.

llvm-svn: 175594

  SltCCRxRy16, SltiCCRxImmX16, SltiuCCRxImmX16, SltuCCRxRy16
$T8 shows up as register $24 when emitted from C++ code so we had
to change some tests that were already there for this functionality.

llvm-svn: 175593

llvm-svn: 175592

llvm-svn: 175591

llvm-svn: 175590

llvm-svn: 175589

<rdar://problem/11540697>

llvm-svn: 175588

control the visibility of a type for the purposes of RTTI
and template argument restrictions independently of how
visibility propagates to its non-type member declarations.

Also fix r175326 to not ignore template argument visibility
on a template explicit instantiation when a member has
an explicit attribute but the instantiation does not.

The type_visibility work is rdar://11880378

llvm-svn: 175587

llvm-svn: 175586

for the data specific to a macro definition (e.g. what the tokens are), and
MacroDirective class which encapsulates the changes to the "macro namespace"
(e.g. the location where the macro name became active, the location where it was undefined, etc.)

(A MacroDirective always points to a MacroInfo object.)

Usually a macro definition (MacroInfo) is where a macro name becomes active (MacroDirective) but
splitting the concepts allows us to better model the effect of modules to the macro namespace
(also as a bonus it allows better modeling of push_macro/pop_macro #pragmas).
Modules can have their own macro history, separate from the local (current translation unit)
macro history; MacroDirectives will be used to model the macro history (changes to macro namespace).

For example, if "@import A;" imports macro FOO, there will be a new local MacroDirective created
to indicate that "FOO" became active at the import location. Module "A" itself will contain another
MacroDirective in its macro history (at the point of the definition of FOO) and both MacroDirectives
will point to the same MacroInfo object.

Introducing the separation of macro concepts is the first part towards better modeling of module macros.

llvm-svn: 175585

llvm-svn: 175584

llvm-svn: 175583

RegionStoreManager::getInterestingValues() returns a pointer to a
std::vector that lives inside a DenseMap, which is constructed on demand.
However, constructing one such value can lead to constructing another
value, which will invalidate the reference created earlier.

Fixed by delaying the new entry creation until the function returns.

llvm-svn: 175582

llvm-svn: 175581

This generalizes Optional to require less from the T type by using aligned
storage for backing & placement new/deleting the T into it when necessary.

Also includes unit tests.

llvm-svn: 175580