[asan] extend the workaround for http://llvm.org/bugs/show_bug.cgi?id=11395: don't instrument the function at all on x86_32 if it has a large asm blob

llvm-svn: 147953

Patch by Brian Anderson.

llvm-svn: 147952

directives was in the wrong place and getting triggered incorectly with a
cpp .file directive.  This change fixes that and adds a test case.

llvm-svn: 147951

llvm-svn: 147949

Fix a bug in the lowering of BUILD_VECTOR for AVX. SCALAR_TO_VECTOR does not zero untouched elements. Use INSERT_VECTOR_ELT instead.

llvm-svn: 147948

Also remove the svn:eol-style property from the test file.

llvm-svn: 147947

are invalid).  Fixes a crash on array1.C from the GCC testsuite when
compiled with dragonegg.

llvm-svn: 147946

strange build bot failures that look like a miscompile into an infloop.
I'll investigate this tomorrow, but I'd both like to know whether my
patch is the culprit, and get the bots back to green.

llvm-svn: 147945

- Support gcc-compatible vfpv3 name in addition to vfp3.
- Support vfpv3-d16.
- Disable neon feature for -mfpu=vfp* (yes, we were emitting Neon instructions
  for those!).

llvm-svn: 147943

lots of lines of code. No functionality changed.

llvm-svn: 147942

SRL-rooted code.

llvm-svn: 147941

factor the differences that were hiding in one of them into its other
caller, the SRL handling code. No change in behavior.

llvm-svn: 147940

mask+shift pairs at the beginning of the ISD::AND case block, and then
hoist the final pattern into a helper function, simplifying and
reflowing it appropriately. This should have no observable behavior
change, but several simplifications fell out of this such as directly
computing the new mask constant, etc.

llvm-svn: 147939

I don't think the compact encoding code is right, but at least is has
defined behavior now.

llvm-svn: 147938

extracts and scaled addressing modes into its own helper function. No
functionality changed here, just hoisting and layout fixes falling out
of that hoisting.

llvm-svn: 147937

detect a pattern which can be implemented with a small 'shl' embedded in
the addressing mode scale. This happens in real code as follows:

  unsigned x = my_accelerator_table[input >> 11];

Here we have some lookup table that we look into using the high bits of
'input'. Each entity in the table is 4-bytes, which means this
implicitly gets turned into (once lowered out of a GEP):

  *(unsigned*)((char*)my_accelerator_table + ((input >> 11) << 2));

The shift right followed by a shift left is canonicalized to a smaller
shift right and masking off the low bits. That hides the shift right
which x86 has an addressing mode designed to support. We now detect
masks of this form, and produce the longer shift right followed by the
proper addressing mode. In addition to saving a (rather large)
instruction, this also reduces stalls in Intel chips on benchmarks I've
measured.

In order for all of this to work, one part of the DAG needs to be
canonicalized *still further* than it currently is. This involves
removing pointless 'trunc' nodes between a zextload and a zext. Without
that, we end up generating spurious masks and hiding the pattern.

llvm-svn: 147936

1. Size heuristics changed. Now we calculate number of unswitching
branches only once per loop.
2. Some checks was moved from UnswitchIfProfitable to
processCurrentLoop, since it is not changed during processCurrentLoop
iteration. It allows decide to skip some loops at an early stage.
Extended statistics:
- Added total number of instructions analyzed.

llvm-svn: 147935

llvm-svn: 147934

llvm-svn: 147933

Protected by an #ifdef, disabled by default.

llvm-svn: 147932

the common *alloc functions as well as a few tiny wibbles (adds a note
to CWE/CERT advisory numbers in the bug output, and fixes a couple
80-column-wide violations.)"

Patch by Austin Seipp!

llvm-svn: 147931

llvm-svn: 147930

Also cygwin has not supported integrated-as yet.

llvm-svn: 147929

llvm-svn: 147928

llvm-svn: 147927

This interface is misleading and dangerous, but it is actually what we need for unrolling.

llvm-svn: 147926

downgrade the default-error warning to an ExtWarn in
C90/99. <rdar://problem/10668057>

llvm-svn: 147925

llvm-svn: 147924

llvm-svn: 147923

Allow LDRD to be formed from pairs with different LDR encodings. This was the original intention of the pass. Somewhere along the way, the LDR opcodes were refined which broke the optimization. We really don't care what the original opcodes are as long as they both map to the same LDRD and the immediate still fits.

Fixes rdar://10435045 ARMLoadStoreOptimization cannot handle mixed LDRi8/LDRi12

llvm-svn: 147922

llvm-svn: 147921

llvm-svn: 147920

llvm-svn: 147919

Add elidable CXXConstructExpr as block-level expr. It converts an lvalue to a rvalue, which is a useful step during AST evaluation.

llvm-svn: 147918

Start refactoring code for capturing variables and 'this' so that it is shared between lambda expressions and block literals.

llvm-svn: 147917

llvm-svn: 147916

to make assumptions if the type is unsized.  We
just give up (and let the JIT handle it) instead.

llvm-svn: 147915

Don't assert but report & return a NULL type if we end up parsing a type we are in the middle of parsing.

llvm-svn: 147914

llvm-svn: 147913

Consider this code:

int h() {
  int x;
  try {
    x = f();
    g();
  } catch (...) {
    return x+1;
  }
  return x;
}

The variable x is undefined on the first edge to the landing pad, but it
has the f() return value on the second edge to the landing pad.

SplitAnalysis::getLastSplitPoint() would assume that the return value
from f() was live into the landing pad when f() throws, which is of
course impossible.

Detect these cases, and treat them as if the landing pad wasn't there.
This allows spill code to be inserted after the function call to f().

<rdar://problem/10664933>

llvm-svn: 147912