llvm-svn: 162900

because C always rounds towards zero.

Thanks Dirk and Ben.

llvm-svn: 162899

llvm-svn: 162898

llvm-svn: 162897

llvm-svn: 162896

code and allow better code reuse. Make the code a bit more conforming
to LLVM code style.
No functionality change.

llvm-svn: 162895

Add FMA to switch statement in VectorLegalizer::LegalizeOp so that it can be expanded when it isn't legal.

llvm-svn: 162894

llvm-svn: 162893

llvm-svn: 162892

support the '-analyzer-config key=val' variant.

llvm-svn: 162891

Also update the tests that rely on c++98 to explicitly mention that.

llvm-svn: 162890

passing additional parameters to a tool.

Use this to fix a FIXME in testing code.

llvm-svn: 162889

llvm-svn: 162888

llvm-svn: 162887

llvm-svn: 162886

llvm-svn: 162885

This improves compatibility with gcc in this regard, and this file generation
can be ameliorated with GCOV_PREFIX and GCOV_PREFIX_STRIP. It's also useful if
your build directory doesn't specify -o <abspath> and it uses a recursive make
structure, so it's not relative to the toplevel.

Patch by Joshua Cranmer!
<rdar://problem/12179524>

llvm-svn: 162884

llvm-svn: 162883

Changes the hash result for strings containing characters
with values >= 128, such as UTF8 strings (not normal ASCII).

Changed mostly so we match other implementations.

llvm-svn: 162882

- The root cause is that target constant materialization in X86 fast-isel
  creates a PC-rel addressing which may overflow 32-bit range in non-Small code
  model if .rodata section is allocated too far away from code segment in
  MCJIT, which uses Large code model so far.
- Follow the similar logic to fix non-Small code model in fast-isel by skipping
  non-Small code model.

llvm-svn: 162881

llvm-svn: 162880

llvm-svn: 162879

When there are multiple tied use-def pairs on an inline asm instruction,
the tied uses must appear in the same order as the defs.

It is possible to write an LLVM IR inline asm instruction that breaks
this constraint, but there is no reason for a front end to emit the
operands out of order.

The gnu inline asm syntax specifies tied operands as a single read/write
constraint "+r", so ouf of order operands are not possible.

llvm-svn: 162878

Avoids surprises when someone uses LLVM_(UN)LIKELY with an integer.

llvm-svn: 162877

inlined function.

This resolves retain count checker false positives that are caused by
inlining ObjC and other methods. Essentially, if we are passing an
object to a method with "delegate" in the selector or a function pointer
as another argument, we should stop tracking the other parameters/return
value as far as the retain count checker is concerned.

llvm-svn: 162876

Thanks Jordan.

llvm-svn: 162875

Tombstones and full hash collisions are rare, mark the "empty"
and "no collision" paths as likely. The bug in simplifycfg
that prevented the hints from being picked during selfhost
up was fixed recently :)

llvm-svn: 162874

llvm-svn: 162873

could not be attached to a CFTypeRef.

Fixes <rdar://problem/12197822>

llvm-svn: 162872

ModuleList::GetSharedModule() returned NULL.

<rdar://problem/12182971>

llvm-svn: 162871

Allow targets to specify a minimum supported NOP size when performing NOP padding.  If the desired padding is smaller than the supported NOP size,
we will enlarge the padding to make it work.

llvm-svn: 162870

For normal instructions, isTied() is set automatically by addOperand(),
based on MCInstrDesc, but inline asm has tied operands outside the
descriptor.

llvm-svn: 162869

Patch by Michael Ilseman!
This fixes SimplifyCFGOpt::FoldValueComparisonIntoPredecessors to preserve metata when folding conditional branches into switches.

void foo(int x) {
  if (x == 0)
    bar(1);
  else if (__builtin_expect(x == 10, 1))
    bar(2);
  else if (x == 20)
    bar(3);
}

CFG:

B0
|  \
|   X0
B10
|  \
|   X10
B20
|  \
E   X20

Merge B0-B10:
w(B0-X0) = w(B0-X0)*sum-weights(B10) = w(B0-X0) * (w(B10-X10) + w(B10-B20))
w(B0-X10) = w(B0-B10) * w(B10-X10)
w(B0-B20) = w(B0-B10) * w(B10-B20)

B0 __
| \  \
| X10 X0
B20
|  \
E  X20

Merge B0-B20:
w(B0-X0) = w(B0-X0) * sum-weights(B20) = w(B0-X0) * (w(B20-E) + w(B20-X20))
w(B0-X10) = w(B0-X10) * sum-weights(B20) = ...
w(B0-X20) = w(B0-B20) * w(B20-X20)
w(B0-E) = w(B0-B20) * w(B20-E)

llvm-svn: 162868

llvm-svn: 162867

llvm-svn: 162866

llvm-svn: 162865

partially).

(Addresses a regression from r162790.)

llvm-svn: 162864

This heuristic addresses the case when a pointer (or ref) is passed
to a function, which initializes the variable (or sets it to something
other than '0'). On the branch where the inlined function does not
set the value, we report use of undefined value (or NULL pointer
dereference). The access happens in the caller and the path
through the callee would get pruned away with regular path pruning. To
solve this issue, we previously disabled diagnostic pruning completely
on undefined and null pointer dereference checks, which entailed very
verbose diagnostics in most cases. Furthermore, not all of the
undef value checks had the diagnostic pruning disabled.

This patch implements the following heuristic: if we pass a pointer (or
ref) to the region (on which the error is reported) into a function and
it's value is either undef or 'NULL' (and is a pointer), do not prune
the function.

llvm-svn: 162863

non-pointer types with a pointer representation correctly. PR13660.

llvm-svn: 162862

Ordered memory operations are more constrained than volatile loads and
stores because they must be ordered with respect to all other memory
operations.

llvm-svn: 162861