llvm-svn: 276011

Added the opencl.ocl.version metadata to be emitted with amdgcn. Created a static function emitOCLVerMD which is shared between triple spir and target amdgcn.

Also added new testcases to existing test file, spir_version.cl inside test/CodeGenOpenCL.

Patch by Aaron En Ye Shi.

Differential Revision: https://reviews.llvm.org/D22424

llvm-svn: 276010

The r600 path has never actually worked sinced double is not implemented
there.

llvm-svn: 276009

We skipped over ReturnInsts which didn't return an argument which would
lead us to incorrectly conclude that an argument returned by another
ReturnInst was 'returned'.

This reverts commit r275756.

This fixes PR28610.

llvm-svn: 276008

I've been hitting those already while working on SCCP and I think
it's be useful to provide a more explanatory diagnostic.

llvm-svn: 276007

llvm-svn: 276006

llvm-svn: 276005

Summary: This flag could be used to disable check in runtime.

Subscribers: kubabrecka

Differential Revision: https://reviews.llvm.org/D22495

llvm-svn: 276004

Summary:
This patch attempts to fix the undefined behavior in __tree by changing the node pointer types used throughout. The pointer types are changed for raw pointers in the current ABI and for fancy pointers in ABI V2 (since the fancy pointer types may not be ABI compatible).

The UB in `__tree` arises because tree downcasts the embedded end node and then deferences that pointer. Currently there are 3 node types in __tree.

* `__tree_end_node` which contains the `__left_` pointer. This node is embedded within the container.
* `__tree_node_base` which contains `__right_`, `__parent_` and `__is_black`. This node is used throughout the tree rebalancing algorithms.
* `__tree_node` which contains `__value_`.

Currently `__tree` stores the start of the tree, `__begin_node_`, as a pointer to a `__tree_node`. Additionally the iterators store their position as a pointer to a `__tree_node`. In both of these cases the pointee can be the end node. This is fixed by changing them to store `__tree_end_node` pointers instead.

To make this change I introduced an `__iter_pointer` typedef which is defined to be a pointer to either `__tree_end_node` in the new ABI or `__tree_node` in the current one.
Both `__tree::__begin_node_` and iterator pointers are now stored as `__iter_pointers`.

The other situation where `__tree_end_node` is stored as the wrong type is in `__tree_node_base::__parent_`.  Currently `__left_`, `__right_`, and `__parent_` are all `__tree_node_base` pointers. Since the end node will only be stored in `__parent_` the fix is to change `__parent_` to be a pointer to `__tree_end_node`.

To make this change I introduced a `__parent_pointer` typedef which is defined to be a pointer to either `__tree_end_node` in the new ABI or `__tree_node_base` in the current one.

Note that in the new ABI `__iter_pointer` and `__parent_pointer` are the same type (but not in the old one). The confusion between these two types is unfortunate but it was the best solution I could come up with that maintains the ABI.

The typedef changes force a ton of explicit type casts to correct pointer types and to make current code compatible with both the old and new pointer typedefs. This is the bulk of the change and it's really messy. Unfortunately I don't know how to avoid it.

Please let me know what you think.





Reviewers: howard.hinnant, mclow.lists

Subscribers: howard.hinnant, bbannier, cfe-commits

Differential Revision: https://reviews.llvm.org/D20786

llvm-svn: 276003

llvm-svn: 276002

- Use unique_ptr instead of managing a container of new'd pointers.
- Use range based for loops.

No functional change is intended.

llvm-svn: 276001

No functional change is intended.

llvm-svn: 276000

No functional change is intended.

llvm-svn: 275999

This code block breaks the docs build (http://lab.llvm.org:8011/builders/llvm-sphinx-docs/builds/11920/steps/docs-llvm-html/logs/stdio), but I cannot see anything immediately wrong with it and cannot reproduce the diagnostic locally. Setting the code highlighting to none instead of nasm to hopefully get the bot stumbling back towards green.

llvm-svn: 275998

NetBSD's system unwinder is a modified version of LLVM's libunwind.
Slightly reduce diffs by updating comments to match theirs where
appropriate.

llvm-svn: 275997

llvm-svn: 275996

llvm-svn: 275995

llvm-svn: 275994

Summary:
The code

  struct A {
    int x[3];
  };

gets an compiler-generated copy constructor that uses ArraySubscriptExpr (see below).
Previously, the check would generate a warning on that copy constructor.
This commit disables the warning on implicitly generated code.
AST:

  |-CXXConstructorDecl 0x337b3c8 <col:8> col:8 implicit used constexpr A 'void (const struct A &) noexcept' inline
  | |-ParmVarDecl 0x337b510 <col:8> col:8 used 'const struct A &'
  | |-CXXCtorInitializer Field 0x3379238 'x' 'int [3]'
  | | `-ImplicitCastExpr 0x337e158 <col:8> 'int' <LValueToRValue>
  | |   `-ArraySubscriptExpr 0x337e130 <col:8> 'const int' lvalue
  | |     |-ImplicitCastExpr 0x337e118 <col:8> 'const int *' <ArrayToPointerDecay>
  | |     | `-MemberExpr 0x337dfc8 <col:8> 'int const[3]' lvalue .x 0x3379238
  | |     |   `-DeclRefExpr 0x337dfa0 <col:8> 'const struct A' lvalue ParmVar 0x337b510 '' 'const struct A &'
  | |     `-ImplicitCastExpr 0x337e098 <col:8> 'unsigned long' <LValueToRValue>
  | |       `-DeclRefExpr 0x337e070 <col:8> 'unsigned long' lvalue Var 0x337e010 '__i0' 'unsigned long'

Reviewers: alexfh, aaron.ballman

Subscribers: aemerson, nemanjai, cfe-commits

Differential Revision: https://reviews.llvm.org/D22381

llvm-svn: 275993

llvm-svn: 275992

llvm-svn: 275991

llvm-svn: 275990

Summary:
Currently, InstCombine is already able to fold expressions of the form `logic(cast(A), cast(B))` to the simpler form `cast(logic(A, B))`, where logic designates one of `and`/`or`/`xor`. This transformation is implemented in `foldCastedBitwiseLogic()` in InstCombineAndOrXor.cpp. However, this optimization will not be performed if both `A` and `B` are `icmp` instructions. The decision to preclude casts of `icmp` instructions originates in r48715 in combination with r261707, and can be best understood by the title of the former one:

> Transform (zext (or (icmp), (icmp))) to (or (zext (cimp), (zext icmp))) if at least one of the (zext icmp) can be transformed to eliminate an icmp.

Apparently, it introduced a transformation that is a reverse of the transformation that is done in `foldCastedBitwiseLogic()`. Its purpose is to expose pairs of `zext icmp` that would subsequently be optimized by `transformZExtICmp()` in InstCombineCasts.cpp. Therefore, in order to avoid an endless loop of switching back and forth between these two transformations, the one in `foldCastedBitwiseLogic()` has been restricted to exclude `icmp` instructions which is mirrored in the responsible check:

`if ((!isa<ICmpInst>(Cast0Src) || !isa<ICmpInst>(Cast1Src)) && ...`

This check seems to sort out more cases than necessary because:
- the reverse transformation is obviously done for `or` instructions only
- and also not every `zext icmp` pair is necessarily the result of this reverse transformation

Therefore we now remove this check and replace it by a more finegrained one in `shouldOptimizeCast()` that now rejects only those `logic(zext(icmp), zext(icmp))` that would be able to be optimized by `transformZExtICmp()`, which also avoids the mentioned endless loop. That means we are now able to also simplify expressions of the form `logic(cast(icmp), cast(icmp))` to `cast(logic(icmp, icmp))` (`cast` being an arbitrary `CastInst`).

As an example, consider the following IR snippet

```
%1 = icmp sgt i64 %a, %b
%2 = zext i1 %1 to i8
%3 = icmp slt i64 %a, %c
%4 = zext i1 %3 to i8
%5 = and i8 %2, %4
```

which would now be transformed to

```
%1 = icmp sgt i64 %a, %b
%2 = icmp slt i64 %a, %c
%3 = and i1 %1, %2
%4 = zext i1 %3 to i8
```

This issue became apparent when experimenting with the programming language Julia, which makes use of LLVM. Currently, Julia lowers its `Bool` datatype to LLVM's `i8` (also see https://github.com/JuliaLang/julia/pull/17225). In fact, the above IR example is the lowered form of the Julia snippet `(a > b) & (a < c)`. Like shown above, this may introduce `zext` operations, casting between `i1` and `i8`, which could for example hinder ScalarEvolution and Polly on certain code.

Reviewers: grosser, vtjnash, majnemer

Subscribers: majnemer, llvm-commits

Differential Revision: https://reviews.llvm.org/D22511

Contributed-by: Matthias Reisinger
llvm-svn: 275989

Only if the value is negative or positive is what matters,
so use a constant that doesn't require an instruction to
materialize.

These should really just emit the write exec directly,
but for stick with the kill pseudo-terminator.

llvm-svn: 275988

This is currently not supported and will only be added later. Also update the
test cases to ensure no invariant code hoisting is applied.

llvm-svn: 275987

Note, ClangRenameTests is linking USRFindingAction.cpp directly.

llvm-svn: 275986

llvm-svn: 275985

llvm-svn: 275984

Submitted by giffunip@yahoo.com; I fixed a couple of nearby errors and
incorrect changes in the patch.

llvm.org/pr27634

llvm-svn: 275983

Summary:
Avoid mismatch between imports/exports for 32-bit and 64-bits version.

The test is running grep over macros to detect which functions are
intercepted. Unfortunately, exception handlers differ in 32-bit and
64-bit.

This patch is removing the exception handlers from the test.

Reviewers: rnk

Subscribers: llvm-commits, wang0109, kubabrecka, chrisha

Differential Revision: https://reviews.llvm.org/D22484

llvm-svn: 275982

D20859 and D20860 attempted to replace the SSE (V)CVTTPS2DQ and VCVTTPD2DQ truncating conversions with generic IR instead.

It turns out that the behaviour of these intrinsics is different enough from generic IR that this will cause problems, INF/NAN/out of range values are guaranteed to result in a 0x80000000 value - which plays havoc with constant folding which converts them to either zero or UNDEF. This is also an issue with the scalar implementations (which were already generic IR and what I was trying to match).

This patch changes both scalar and packed versions back to using x86-specific builtins.

It also deals with the other scalar conversion cases that are runtime rounding mode dependent and can have similar issues with constant folding.

A companion clang patch is at D22105

Differential Revision: https://reviews.llvm.org/D22106

llvm-svn: 275981

Summary:
No functional changes in this patch. It is a refactoring (pull out a
structure representing the symbol being queried).

This is a preparing step for inserting missing namespace qualifiers to all
instances of an unidentified symbol.

Reviewers: bkramer

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D22510

llvm-svn: 275980

Recommitting after r274347 was reverted. This patch introduces some
classes to refactor the 3 and 4 register Thumb2 multiplication
instruction descriptions, plus improved tests for some of those
instructions.

Differential Revision: https://reviews.llvm.org/D21929

llvm-svn: 275979

Adding PredictableSelectIsExpensive for Vulcan

Differential Revision: https://reviews.llvm.org/D22448

llvm-svn: 275978

    
The standard local dynamic model for TLS on ARM systems needs two 
relocations:
- R_ARM_TLS_LDM32 (module idx)
- R_ARM_TLS_LDO32 (offset of object from origin of module TLS block)
    
In GNU style assembler we use symbol(tlsldm) and symbol(tlsldo) to
produce these relocations.
    
llvm-mc for ARM supports symbol(tlsldo) but does not support symbol(tlsldm).
This patch wires up the existing symbol(tlsldm) to R_ARM_TLS_LDM32.
    
TLS for ARM is defined in Addenda to, and Errata in, the ABI for the
ARM Architecture
    
Differential Revision: https://reviews.llvm.org/D22461

llvm-svn: 275977

As promised in D22191

llvm-svn: 275976

llvm-svn: 275975

More info http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/14774/steps/check-clang%20msan/logs/stdio

llvm-svn: 275974

As discussed on PR27654, this patch fixes the triples of a lot of aarch64 tests and enables lit tests on windows

This will hopefully help stop cases where windows developers break the aarch64 target

Differential Revision: https://reviews.llvm.org/D22191

llvm-svn: 275973

llvm-svn: 275972