directly.

This is in preparation for removing the use of the 'Attribute' class as a
collection of attributes. That will shift to the AttributeSet class instead.

llvm-svn: 171253

llvm-svn: 171252

LCSSA PHIs may have undef values. The vectorizer updates values that are used by outside users such as PHIs.
The bug happened because undefs are not loop values. This patch handles these PHIs.

PR14725

llvm-svn: 171251

This is done to avoid odd test failures, like the one fixed in r171243.

llvm-svn: 171250

* One that accepts a single Attribute::AttrKind.

* One that accepts an Attribute::AttrKind plus a list of values. This is for
  attributes defined like this:

    #1 = attributes { align = 4 }

* One that accepts a string, for target-specific attributes like this:

    #2 = attributes { "cpu=cortex-a8" }

llvm-svn: 171249

This test did not test anything at all (except for opt crashing, but that was
not the reason why it was added).

llvm-svn: 171248

stored here is of a certain kind. This is in preparation for when an Attribute
object represents a single attribute, instead of a bitmask of attributes.

llvm-svn: 171247

This is done to avoid odd test failures, like the one fixed in r171243.

llvm-svn: 171246

already uniquified.

Note: This will be expanded in the future to add more than just one pointer
value.

llvm-svn: 171245

s/Raw/getBitMask/g to be more in line with current naming conventions. This method won't be sticking around.

llvm-svn: 171244

Larry Evans reported it fails if source tree contains "load", like "download".

llvm-svn: 171243

assert(Condition
       && "Text");

->

assert(Condition &&
       "Text);

This aligns Polly with the style used in LLVM.

llvm-svn: 171242

We fix the following formatting problems found by clang-format:

  - 80 cols violations
  - Obvious problems with missing or too many spaces
  - multiple new lines in a row

clang-format suggests many more changes, most of them falling in the following
two categories:

  1) clang-format does not at all format a piece of code nicely

  2) The style that clang-format suggests does not match the style used in
     Polly/LLVM

I consider differences caused by reason 1) bugs, which should be fixed by
improving clang-format. Differences due to 2) need to be investigated closer
to understand the cause of the difference and the solution that should be taken.

llvm-svn: 171241

This fixes pr14736. It is fairly ugly, but I don't think we can do much better
as we have to wait at least until the end of the typedef to know if the
function will have external linkage or not.

llvm-svn: 171240

llvm-svn: 171239

llvm-svn: 171238

Remove intrinsic specific instructions for (V)SQRTPS/PD. Instead lower to target-independent ISD nodes and use the existing patterns for those.

llvm-svn: 171237

Remove test for eof from istreambuf_iterator constructors.  It is no longer necessary and potentially violates the constructor's noexcept spec.

llvm-svn: 171232

llvm-svn: 171231

llvm-svn: 171229

Polly - Performing polyhedral optimizations on a low-level intermediate
representation

Tobias Grosser, Armin Groesslinger, Christian Lengauer Parallel
Processing Letters 2012 22:04

llvm-svn: 171228

Remove intrinsic specific instructions for SSE/SSE2/AVX floating point max/min instructions. Lower them to target specific nodes and use those patterns instead. This also allows them to be commuted if UnsafeFPMath is enabled.

llvm-svn: 171227

llvm-svn: 171226

llvm-svn: 171225

llvm-svn: 171224

llvm-svn: 171223

get the wrong answer. Wasn't caught by my implementation sadly...

llvm-svn: 171222

llvm-svn: 171221

llvm-svn: 171220

to read and tell that it is a SWO -- we now descend through the
components and return a result at the first inequal component.

Also comment it a bit better and make it a total ordering by sorting on
the text of the suffix if necessary.

None of this should really be a visible change.

llvm-svn: 171219

llvm-svn: 171218

[asan] add a new interface function __asan_describe_address, useful for running asan-ified binary under a debugger (e.g. gdb)

llvm-svn: 171217

DS parameter  has a default (null) value anyway, so there's no need for an
if/else here.
Patch by Nikola Smiljanić.

llvm-svn: 171210

inlined.  These do not need to be always-inlined for ABI stability because they are not exported beyond this source due to the unnamed namespace.
Also simplified use of the Wmissing-field-initializers pragma as was done for clang.

llvm-svn: 171202

llvm-svn: 171200

llvm-svn: 171199

[asan] implement more strict checking for memset/etc parameters. Instead of checking the first and the last byte, we check the entire shadow region. This costs ~10 slowdown for the instrumented functions. Motivated by a nasty memset-buffer-overflow-by-140-bytes in chrome which was reported as a use-after-free or not at all

llvm-svn: 171198

deleted this, but apparantly not. Charmingly, Clang didn't warn on it
but GCC did.

llvm-svn: 171197

propagating one of the values it simplified to a constant across
a myriad of instructions. Notably, ptrtoint instructions when we had
a constant pointer (say, 0) didn't propagate that, blocking a massive
number of down-stream optimizations.

This was uncovered when investigating why we fail to inline and delete
the boilerplate in:

  void f() {
    std::vector<int> v;
    v.push_back(1);
  }

It turns out most of the efforts I've made thus far to improve the
analysis weren't making it far purely because of this. After this is
fixed, the store-to-load forwarding patch enables LLVM to optimize the
above to an empty function. We still can't nuke a second push_back, but
for different reasons.

There is a very real chance this will cause somewhat noticable changes
in inlining behavior, so please let me know if you see regressions (or
improvements!) because of this patch.

llvm-svn: 171196

how to propagate constants through insert and extract value
instructions.

With the recent improvements to instsimplify, this allows inline cost
analysis to constant fold through intrinsic functions, including notably
the with.overflow intrinsic math routines which often show up inside of
STL abstractions. This is yet another piece in the puzzle of breaking
down the code for:

  void f() {
    std::vector<int> v;
    v.push_back(1);
  }

But it still isn't enough. There are a pile of bugs in inline cost still
blocking this.

llvm-svn: 171195