llvm-svn: 349760

As discussed on D55894, this replaces the existing PADDS/PSUBUS intrinsics with the the sadd/ssub.sat generic intrinsics and moves the tests out of the x86 subfolder.

PR40110 has been raised to fix the regression with constant folding vectors containing undef elements.

llvm-svn: 349759

llvm-svn: 349758

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

llvm-svn: 349757

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

llvm-svn: 349756

llvm-svn: 349755

llvm-svn: 349754

This adds assembly-level tests to verify that the high-level
intrinsics generate the instructions they're supposed to.
These tests would have caught the codegen bugs I just fixed.

llvm-svn: 349753

Replace multiple comparisons of getOS() value with FreeBSD, NetBSD,
OpenBSD and DragonFly with matching isOS*BSD() methods.  This should
improve the consistency of coding style without changing the behavior.
Direct getOS() comparisons were left whenever used in switch or switch-
like context.

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

llvm-svn: 349752

The following two bugs in SystemZ high-level vector intrinsics are
fixes by this patch:

- The float case of vec_insert_and_zero should generate a VLLEZF
  pattern, but currently erroneously generates VLLEZLF.

- The float and double versions of vec_orc erroneously generate
  and-with-complement instead of or-with-complement.

The patch also fixes a couple of typos in the associated test.

llvm-svn: 349751

Reviewers: ilya-biryukov

Subscribers: ioeric, MaskRay, jkorous, arphaman, kadircet, cfe-commits

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

llvm-svn: 349750

This patch fixes two deficiencies in current code that recognizes
the VLLEZ idiom:

- For the floating-point versions, we have ISel patterns that match
  on a bitconvert as the top node.  In more complex cases, that
  bitconvert may already have been merged into something else.
  Fix the patterns to match the inner nodes instead.

- For the 64-bit integer versions, depending on the surrounding code,
  we may get either a DAG tree based on JOIN_DWORDS or one based on
  INSERT_VECTOR_ELT.  Use a PatFrags to simply match both variants.

llvm-svn: 349749

Current code in SystemZDAGToDAGISel::tryGather refuses to perform
any transformation if the Load SDNode has more than one use.  This
(erronously) counts uses of the chain result, which prevents the
optimization in many cases unnecessarily.  Fixed by this patch.

llvm-svn: 349748

Update PPC ir following GEP->bitcat to bitcat->GEP->bitcat change.

llvm-svn: 349747

We already have special code (DAG combine support for FP_ROUND)
to recognize cases where we an use a vector version of VLEDB to
perform two floating-point truncates in parallel, but equivalent
support for VLEDB (vector floating-point extends) has been
missing so far.  This patch adds corresponding DAG combine
support for FP_EXTEND.

llvm-svn: 349746

This reverts commit r349699.
Reason: the commit breaks compilation of sanitizer_rtems.cc when
building for RTEMS.

llvm-svn: 349745

Pulled out of D55894 to match the clang changes in D55890.

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

llvm-svn: 349744

This emits SADD_SAT/SSUB_SAT generic intrinsics for the SSE signed saturated math intrinsics.

LLVM counterpart: https://reviews.llvm.org/D55894

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

llvm-svn: 349743

As discussed on D55894, this makes no difference to the actual test.

llvm-svn: 349742

This was requested during the review of D55886.
(sorry, forgot to address this)

llvm-svn: 349741

llvm-svn: 349740

Those intrinsics will be autoupgraded soon to @llvm.sadd.sat generics (D55894), so to keep a x86-specific case I'm replacing it with @llvm.x86.sse2.pmulhu.w

llvm-svn: 349739

This is https://bugs.llvm.org/show_bug.cgi?id=40005,

Patch teaches llvm-objcopy to preserve OS/ABI and ABIVersion fields of ELF header.
(Currently, it drops them to zero).

Differential revision: https://reviews.llvm.org/D55886

llvm-svn: 349738

These tools were assuming ABI version is 0,
that is not always true.

Patch teaches them to work with that field.

Differential revision: https://reviews.llvm.org/D55884

llvm-svn: 349737

llvm-svn: 349736

Summary:
Include the following intrinsics in the InsctCombine
simplification:

* amdgcn_raw_buffer_load
* amdgcn_raw_buffer_load_format
* amdgcn_struct_buffer_load
* amdgcn_struct_buffer_load_format

Change-Id: I14deceff74bcb21179baf6aa6e94bf39e7d63d5d

Reviewers: arsenm

Reviewed By: arsenm

Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, llvm-commits

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

llvm-svn: 349735

LLVM treats void* pointers passed to assembly routines as pointers to
sized types.
We used to emit calls to __msan_instrument_asm_load() for every such
void*, which sometimes led to false positives.
A less error-prone (and truly "conservative") approach is to unpoison
only assembly output arguments.

llvm-svn: 349734

Forgot to update PowerPC tests for the GEP->bitcast change.

llvm-svn: 349733

lib/Analysis/VectorUtils.cpp:482:2: warning: extra ‘;’ [-Wpedantic]

llvm-svn: 349732

Summary:
This allows expanding {7,11,13,14,15,21,22,23,25,26,27,28,29,30,31}-byte memcmp
in just two loads on X86. These were previously calling memcmp.

Reviewers: spatel, gchatelet

Subscribers: llvm-commits

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

llvm-svn: 349731

This is patch complements D55117 implementing __hwasan_mem*
functions in runtime

Differential revision: https://reviews.llvm.org/D55554

llvm-svn: 349730

Summary:
Handles expressions such as:
 - `std::is_const<T>()`
 - `std::is_const<T>()()`;
 - `std::is_same(decltype(U()), V>::value`;

Reviewers: aaron.ballman, Quuxplusone

Subscribers: cfe-commits, llvm-commits

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

llvm-svn: 349729

Differential revision: https://reviews.llvm.org/D55117

llvm-svn: 349728

Summary:
PowerPC has scalar selects (isel) and vector mask selects (xxsel). But PowerPC
does not have vector CR selects, PowerPC does not support scalar condition 
selects on vectors.
In addition to implementing this hook, isSelectSupported() should return false
when the SelectSupportKind is ScalarCondVectorVal, so that predictable selects
are converted into branch sequences.

Reviewed By: steven.zhang,  hfinkel

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

llvm-svn: 349727

llvm-svn: 349726

The current llvm.mem.parallel_loop_access metadata has a problem in that
it uses LoopIDs. LoopID unfortunately is not loop identifier. It is
neither unique (there's even a regression test assigning the some LoopID
to multiple loops; can otherwise happen if passes such as LoopVersioning
make copies of entire loops) nor persistent (every time a property is
removed/added from a LoopID's MDNode, it will also receive a new LoopID;
this happens e.g. when calling Loop::setLoopAlreadyUnrolled()).
Since most loop transformation passes change the loop attributes (even
if it just to mark that a loop should not be processed again as
llvm.loop.isvectorized does, for the versioned and unversioned loop),
the parallel access information is lost for any subsequent pass.

This patch unlinks LoopIDs and parallel accesses.
llvm.mem.parallel_loop_access metadata on instruction is replaced by
llvm.access.group metadata. llvm.access.group points to a distinct
MDNode with no operands (avoiding the problem to ever need to add/remove
operands), called "access group". Alternatively, it can point to a list
of access groups. The LoopID then has an attribute
llvm.loop.parallel_accesses with all the access groups that are parallel
(no dependencies carries by this loop).

This intentionally avoid any kind of "ID". Loops that are clones/have
their attributes modifies retain the llvm.loop.parallel_accesses
attribute. Access instructions that a cloned point to the same access
group. It is not necessary for each access to have it's own "ID" MDNode,
but those memory access instructions with the same behavior can be
grouped together.

The behavior of llvm.mem.parallel_loop_access is not changed by this
patch, but should be considered deprecated.

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

llvm-svn: 349725

Summary:
This is a code size savings and is also important to get runnable code
while engines do not support v128.const.

Reviewers: aheejin, dschuff

Subscribers: sbc100, jgravelle-google, sunfish, llvm-commits

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

llvm-svn: 349724

llvm-svn: 349723

llvm-svn: 349722

llvm-svn: 349721