[AArch64][SVE] Implement abs and neg intrinsics

Summary:
This patch implements two arithmetic intrinsics:

      * int_aarch64_sve_abs
      * int_aarch64_sve_neg

testing the support for scalable vector types in intrinsics added in D65930.

Reviewed By: greened

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

llvm-svn: 371388

[ARM] Prevent generating NEON stack accesses under MVE.

We should not be generating Neon stack loads/stores even for these large
registers.

No test here because my understanding is we will only generate these QQPR regs
for intrinsics and VLDn's. The tests will follow once those are available.

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

llvm-svn: 371386

GlobalISel: fix unused warnings in release builds.

llvm-svn: 371385

GlobalISel: add combiner to form indexed loads.

Loosely based on DAGCombiner version, but this part is slightly simpler in
GlobalIsel because all address calculation is performed by G_GEP. That makes
the inc/dec distinction moot so there's just pre/post to think about.

No targets can handle it yet so testing is via a special flag that overrides
target hooks.

llvm-svn: 371384

[yaml2obj] - Fix BB after r371380

Just a fix for an input file name.

llvm-svn: 371383

[lib/ObjectYAML] - Improve and cleanup error reporting in ELFState<ELFT> class.

The aim of this patch is to refactor how we handle and report error.

I suggest to use the same approach we use in LLD: delayed error reporting.
For that I introduced 'HasError' flag which triggers when we report an error.
Now we do not exit instantly on any error. The benefits are:

1) There are no more 'exit(1)' calls in the library code.
2) Code was simplified significantly in a few places.
3) It is now possible to print multiple errors instead of only one.

Also, I changed the messages to be lower case and removed a full stop.

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

llvm-svn: 371380

[clangd] Highlight typedefs to template parameters as template parameters

Summary:
Template parameters were handled outside `addType`, this led to lack of highlightings for typedefs
to template types.

This was never desirable, we want to highlight our typedefs as their underlying type.
Note that typedefs to more complicated types, like pointers and references are still not highlighted.

Original patch by Johan Vikström.

Reviewers: hokein, jvikstrom

Reviewed By: hokein

Subscribers: nridge, javed.absar, kristof.beyls, MaskRay, jkorous, arphaman, kadircet, cfe-commits

Tags: #clang

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

llvm-svn: 371379

[clangd] Replace HighlightingKind::NumKinds with LastKind. NFC

Summary:
The latter simplifies the client code by avoiding the need to handle it
as a separate case statement.

Reviewers: hokein

Reviewed By: hokein

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

Tags: #clang

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

llvm-svn: 371375

[ARM][MVE] Decoding of uqrshl and sqrshl accepts unpredictable encodings

Specify the Unpredictable bits, and return softfails when appropriate.

Patch by Mark Murray!

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

llvm-svn: 371374

[clangd] Improve output of semantic highlighting tests in case of failures

Summary:
Instead of matching lists of highlightings, we annotate input code with
resulting highlightings and diff it against the expected annotated input.

In case of failures, this produces much nicer output in form of text-based
diffs.

Reviewers: hokein

Reviewed By: hokein

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

Tags: #clang

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

llvm-svn: 371373

[ARM][ParallelDSP] Fix for sext input

The incoming accumulator value can be discovered through a sext, in
which case there will be a mismatch between the input and the result.
So sign extend the accumulator input if we're performing a 64-bit mac.

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

llvm-svn: 371370

[SystemZ]  NFC: use clearRegisterDeads() in SystemZElimCompare.cpp

This is simpler than using findRegisterDefOperandIdx() + setIsDead().

Review: Ulrich Weigand.
llvm-svn: 371369

[X86] Add broadcast load unfolding support for vpcmpeq/vpcmpgt/vpcmp/vpcmpu.

llvm-svn: 371368

[X86] Add broadcast load unfolding tests for vpcmpeq/vpcmpgt/vpcmp/vpcmpu.

llvm-svn: 371367

[X86] Add broadcast load unfold support for smin/umin/smax/umax.

llvm-svn: 371366

[X86] Add broadcast load unfolding tests for smin/umin/smax/smin.

llvm-svn: 371365

AMDGPU: Remove pointless wrapper nodes for init.exec intrinsics

llvm-svn: 371364

[X86] Add broadcast load unfolding support for VMAXPS/PD and VMINPS/PD.

llvm-svn: 371363

[X86] Add broadcast load unfolding tests for vmaxps/pd and vminps/pd

llvm-svn: 371362

[ELF][test] Improve and reorganize another set of tests

Add file-level comments
Replace trivial Input/*.s with echo ... | llvm-mc
Delete insignificant addresses to make them more tolerant to layout changes
Simplify test output

Merge merge-section-types.s into compatible-section-types.s and add a missed case
Merge gnu-ifunc-gotpcrel.s (added in D19517) into gnu-ifunc-dso.s (added in D35119) and add missed cases
Delete typed-undef.s - covered by executable-undefined-ignoreall.s
Delete emit-relocs-shared.s - covered by emit-relocs-merge.s

Replace copy-rel-pie.s and copy-rel-pie2.s with canonical-plt-pcrel.s, canonical-plt-symbolic.s and copy-rel.s:
add -no-pie cases.
add a case that a canonical PLT can be created for STT_GNU_IFUNC. The logic in Symbols.h was untested:

  // ctor of SharedSymbol
  if (this->type == llvm::ELF::STT_GNU_IFUNC)
    this->type = llvm::ELF::STT_FUNC;

llvm-svn: 371361

[X86] Add fp128 test cases for ceil/floor/trunc/nearbyint/rint/round libcalls.

llvm-svn: 371360

[MachineCopyPropagation] Remove redundant copies after TailDup via machine-cp

Summary:
After tailduplication, we have redundant copies. We can remove these
copies in machine-cp if it's safe to, i.e.
```
$reg0 = OP ...
... <<< No read or clobber of $reg0 and $reg1
$reg1 = COPY $reg0 <<< $reg0 is killed
...
<RET>
```
will be transformed to
```
$reg1 = OP ...
...
<RET>
```

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

llvm-svn: 371359

[X86] Add test cases for fptoui/fptosi/sitofp/uitofp between fp128 and i128.

llvm-svn: 371358

[X86] Use xorps to create fp128 +0.0 constants.

This matches what we do for f32/f64. gcc also does this for fp128.

llvm-svn: 371357

[X86] Add avx and avx512f RUN lines to fp128-cast.ll

llvm-svn: 371356

Relax opcode checks in test to check for only a number instead of a specific number.

llvm-svn: 371355

Enable LSan for NetBSD/i386 in test/asan/lit.cfg.py

llvm-svn: 371354

[X86][SSE] SimplifyDemandedVectorEltsForTargetNode - add faux shuffle support.

This patch decodes target and faux shuffles with getTargetShuffleInputs - a reduced version of resolveTargetShuffleInputs that doesn't resolve SM_SentinelZero cases, so we can correctly remove zero vectors if they aren't demanded.

llvm-svn: 371353

[InstCombine][NFC] Some tests for usub overflow+nonzero check improvement (PR43251)

https://rise4fun.com/Alive/kHq

https://bugs.llvm.org/show_bug.cgi?id=43251

llvm-svn: 371352

[X86] Add a hack to combineVSelectWithAllOnesOrZeros to turn selects with two zero/undef vector inputs into an all zeroes vector.

If the two zero vectors have undefs in different places they
won't get combined by simplifySelect.

This fixes a regression from an earlier commit.

llvm-svn: 371351

[X86] Remove call to getZeroVector from materializeVectorConstant. Add isel patterns for zero vectors with all types.

The change to avx512-vec-cmp.ll is a regression, but should be
easy to fix. It occurs because the getZeroVector call was
canonicalizing both sides to the same node, then SimplifySelect
was able to simplify it. But since only called getZeroVector
on some VTs this isn't a robust way to combine this.

The change to vector-shuffle-combining-ssse3.ll is more
instructions, but removes a constant pool load so its unclear
if its a regression or not.

llvm-svn: 371350

[InstSimplify] simplifyUnsignedRangeCheck(): if we know that X != 0, handle more cases (PR43246)

Summary:
This is motivated by D67122 sanitizer check enhancement.
That patch seemingly worsens `-fsanitize=pointer-overflow`
overhead from 25% to 50%, which strongly implies missing folds.

In this particular case, given
```
char* test(char& base, unsigned long offset) {
  return &base + offset;
}
```
it will end up producing something like
https://godbolt.org/z/LK5-iH
which after optimizations reduces down to roughly
```
define i1 @t0(i8* nonnull %base, i64 %offset) {
  %base_int = ptrtoint i8* %base to i64
  %adjusted = add i64 %base_int, %offset
  %non_null_after_adjustment = icmp ne i64 %adjusted, 0
  %no_overflow_during_adjustment = icmp uge i64 %adjusted, %base_int
  %res = and i1 %non_null_after_adjustment, %no_overflow_during_adjustment
  ret i1 %res
}
```
Without D67122 there was no `%non_null_after_adjustment`,
and in this particular case we can get rid of the overhead:

Here we add some offset to a non-null pointer,
and check that the result does not overflow and is not a null pointer.
But since the base pointer is already non-null, and we check for overflow,
that overflow check will already catch the null pointer,
so the separate null check is redundant and can be dropped.

Alive proofs:
https://rise4fun.com/Alive/WRzq

There are more patterns of "unsigned-add-with-overflow", they are not handled here,
but this is the main pattern, that we currently consider canonical,
so it makes sense to handle it.

https://bugs.llvm.org/show_bug.cgi?id=43246

Reviewers: spatel, nikic, vsk

Reviewed By: spatel

Subscribers: hiraditya, llvm-commits, reames

Tags: #llvm

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

llvm-svn: 371349

[InstCombine] add tests for icmp with srem operand; NFC

llvm-svn: 371348

[X86] X86DAGToDAGISel::combineIncDecVector(): call getSplatBuildVector() manually

As reported in post-commit review of r370327,
there is some case where the code crashes.

As discussed with Craig Topper, the problem is that getConstant()
internally calls getSplatBuildVector(), so we don't insert
the constant itself.

If we do that manually we're good.

llvm-svn: 371346

[X86] Use DAG.getConstant instead of getZeroVector in combinePMULDQ.

getZeroVector canonicalizes the type to vXi32, but that's a
legalization action. We should use the most correct type if
possible.

llvm-svn: 371345

[DAGCombiner][X86][ARM] Teach visitMULO to fold multiplies with 0 to 0 and no carry.

I modified the ARM test to use two inputs instead of 0 so the
test hopefully still tests what was intended.

llvm-svn: 371344

[X86] Teach materializeVectorConstant to not call getZeroVector/getOnesVector on the types we already have isel patterns for.

llvm-svn: 371343

Move prop-sink branch to monorepo.

llvm-svn: 371342

[InstCombine] fold extract+insert into identity shuffle

This is similar to the existing fold for splats added with:
rL365379

If we can adjust the shuffle mask to include another element
in an identity mask (if it changes vector length, that's an
extract/insert subvector operation in the backend), then that
can eliminate extractelement/insertelement pairs in IR.

All targets are expected to lower shuffles with identity masks
efficiently.

llvm-svn: 371340

[NFC][InstSimplify] Some tests for dropping null check after uadd.with.overflow of non-null (PR43246)

https://rise4fun.com/Alive/WRzq

Name: C <= Y && Y != 0  -->  C <= Y  iff C != 0
Pre: C != 0
  %y_is_nonnull = icmp ne i64 %y, 0
  %no_overflow = icmp ule i64 C, %y
  %r = and i1 %y_is_nonnull, %no_overflow
=>
  %r = %no_overflow

Name: C <= Y || Y != 0  -->  Y != 0  iff C != 0
Pre: C != 0
  %y_is_nonnull = icmp ne i64 %y, 0
  %no_overflow = icmp ule i64 C, %y
  %r = or i1 %y_is_nonnull, %no_overflow
=>
  %r = %y_is_nonnull

Name: C > Y || Y == 0  -->  C > Y  iff C != 0
Pre: C != 0
  %y_is_null = icmp eq i64 %y, 0
  %overflow = icmp ugt i64 C, %y
  %r = or i1 %y_is_null, %overflow
=>
  %r = %overflow

Name: C > Y && Y == 0  -->  Y == 0  iff C != 0
Pre: C != 0
  %y_is_null = icmp eq i64 %y, 0
  %overflow = icmp ugt i64 C, %y
  %r = and i1 %y_is_null, %overflow
=>
  %r = %y_is_null

https://bugs.llvm.org/show_bug.cgi?id=43246

llvm-svn: 371339

Enable LSan tests for NetBSD/i386

llvm-svn: 371338

Stop marking 5 ASan tests as failing on NetBSD/i386

Unexpected Passing Tests (4):
    AddressSanitizer-i386-netbsd :: TestCases/Posix/coverage-reset.cpp
    AddressSanitizer-i386-netbsd :: TestCases/Posix/coverage.cpp
    AddressSanitizer-i386-netbsd :: TestCases/Posix/interception-in-shared-lib-test.cpp
    AddressSanitizer-i386-netbsd :: TestCases/suppressions-library.cpp

llvm-svn: 371337

[ASan] Only run dlopen-mixed-c-cxx.c with static runtime

This is what the original bug (http://llvm.org/PR39641) and the fix
in https://reviews.llvm.org/D63877 have been about.
With the dynamic runtime the test only passes when the asan library
is linked against libstdc++: In contrast to libc++abi, it does not
implement __cxa_rethrow_primary_exception so the regex matches the
line saying that asan cannot intercept this function. Indeed, there
is no message that the runtime failed to intercept  __cxa_throw.

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

llvm-svn: 371336

Enable leak-detection for NetBSD/amd64 in test/asan

llvm-svn: 371335

Do not intercept malloc_usable_size on NetBSD

llvm-svn: 371334

[DebugInfo][X86] Describe call site values for zero-valued imms

Summary:
Add zero-materializing XORs to X86's describeLoadedValue() hook in order
to produce call site values.

I have had to change the defs logic in collectCallSiteParameters() a bit
to be able to describe the XORs. The XORs implicitly define $eflags,
which would cause them to never be considered, due to a guard condition
that I->getNumDefs() is one. I have changed that condition so that we
now only consider instructions where a forwarded register overlaps with
the instruction's single explicit define. We still need to collect the implicit
defines of other forwarded registers to remove them from the work list.
I'm not sure how to move towards supporting instructions with multiple
explicit defines, cases where forwarded register are implicitly defined,
and/or cases where an instruction produces values for multiple forwarded
registers. Perhaps the describeLoadedValue() hook should take a register
argument, and we then leave it up to the hook to describe the loaded
value in that register? I have not yet encountered a situation where
that would be necessary though.

Reviewers: aprantl, vsk, djtodoro, NikolaPrica

Reviewed By: vsk

Subscribers: ychen, hiraditya, llvm-commits

Tags: #debug-info, #llvm

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

llvm-svn: 371333

[NFC] Make the describeLoadedValue() hook return machine operand objects

Summary:
This changes the ParamLoadedValue pair which the describeLoadedValue()
hook returns so that MachineOperand objects are returned instead of
pointers.

When describing call site values we may need to describe operands which
are not part of the instruction. One such example is zero-materializing
XORs on x86, which I have implemented support for in a child revision.
Instead of having to return a pointer to an operand stored somewhere
outside the instruction, start returning objects directly instead, as
that simplifies the code.

The MachineOperand class only holds POD members, and on x86-64 it is 32
bytes large. That combined with copy elision means that the overhead of
returning a machine operand object from the hook does not become very
large.

I benchmarked this on a 8-thread i7-8650U machine with 32 GB RAM. The
benchmark consisted of building a clang 8.0 binary configured with:

  -DCMAKE_BUILD_TYPE=RelWithDebInfo \
  -DLLVM_TARGETS_TO_BUILD=X86 \
  -DLLVM_USE_SANITIZER=Address \
  -DCMAKE_CXX_FLAGS="-Xclang -femit-debug-entry-values -stdlib=libc++"

The average wall clock time increased by 4 seconds, from 62:05 to
62:09, which is an 0.1% increase.

Reviewers: aprantl, vsk, djtodoro, NikolaPrica

Reviewed By: vsk

Subscribers: hiraditya, ychen, llvm-commits

Tags: #debug-info, #llvm

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

llvm-svn: 371332

[ARM] Remove declaration of unimplemented function. NFC.

llvm-svn: 371331

[X86][SSE] Fix out of range shift introduced in D67070/rL371328

Use APInt to create the comparison mask instead.

llvm-svn: 371330

[X86] Add test case for PR32546

llvm-svn: 371329

[X86][SSE] Add support for <64 x i1> bool reduction

This generalizes the existing <32 x i1> pre-AVX2 split code to support reductions from <64 x i1> as well, we can probably generalize to any larger pow2 case in the future if the (unlikely) need ever arises.

We still need to tweak combineBitcastvxi1 to improve AVX512F codegen as its assumes vXi1 types should be handled on the mask registers even when they aren't legal.

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

llvm-svn: 371328

[StackMap] Current stackmap version should be 3. NFC.

llvm-svn: 371327

[NewPM][Sancov] Create the Sancov Pass after building the pipelines

We're running into linker errors from missing sancov sections:

```
ld.lld: error: relocation refers to a discarded section: __sancov_guards
>>> defined in user-arm64-ubsan-sancov-full.shlib/obj/third_party/ulib/scudo/scudo.wrappers_c.cc.o
>>> referenced by common.h:26 (../../zircon/third_party/ulib/scudo/common.h:26)
... many other references
```

I believe this is due to a pass in the default pipeline that somehow discards
these sections. The ModuleSanitizerCoveragePass was initially added at the
start of the pipeline. This now adds it to the end of the pipeline for
optimized and unoptimized builds.

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

llvm-svn: 371326

[X86] Make getZeroVector return floating point vectors in their native type on SSE2 and later.

isel used to require zero vectors to be canonicalized to a single
type to minimize the number of patterns needed to match. This is
 no longer required.

I plan to do this to integers too, but floating point was simpler
to start with. Integer has a complication where v32i16/v64i8 aren't
legal when the other 512-bit integer types are.

llvm-svn: 371325

Remove ::gets for FreeBSD 13 and later

Summary:
In https://svnweb.freebsd.org/changeset/base/351659 @emaste removed gets() from
FreeBSD 13's libc, and our copies of libc++ and libstdc++.  In that change, the
declarations were simply deleted, but I would like to propose this conditional
test instead.

Reviewers: EricWF, mclow.lists, emaste

Reviewed By: mclow.lists

Subscribers: krytarowski, christof, ldionne, emaste, libcxx-commits

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

llvm-svn: 371324

[X86] Add support for unfold broadcast loads from FMA instructions.

llvm-svn: 371323

[X86] Add broadcast load unfolding tests for FMA instructions.

llvm-svn: 371322

[aarch64] Add combine patterns for fp16 fmla

This patch enables generation of fused multiply add/sub for instructions operating on fp16.
Tested on aarch64-linux.

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

llvm-svn: 371321

Fixes an assertion while instantiating a template with an incomplete typo-corrected type.

Fixes PR35682. When a template in instantiated with an incomplete typo corrected type an assertion can trigger if the -ferror-limit is used to reduce the number of errors.

Patch by Mark de Wever.

llvm-svn: 371320

[X86] Add prefer-128-bit subtarget feature.

Summary:
Similar to the previous prefer-256-bit flag. We might want to
enable this by default some CPUs. This just starts the initial
work to implement and prove that it effects TTI's vector width.

Reviewers: RKSimon, echristo, spatel, atdt

Reviewed By: RKSimon

Subscribers: lebedev.ri, hiraditya, llvm-commits

Tags: #llvm

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

llvm-svn: 371319

[llvm-nm] - Fix a bug and unbreak ASan BB.

BB: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/builds/13820/steps/check-llvm%20asan/logs/stdio

rL371074 revealed a bug in llvm-nm.

This patch fixes it.

llvm-svn: 371318

Fix typo. NFCI

llvm-svn: 371317

[mips] Follow-up to r371313 - fix failed test case. NFC

llvm-svn: 371316

[X86] Avoid uses of getZextValue(). NFCI.

Use getAPIntValue() directly - this is mainly a best practice style issue to help prevent fuzz tests blowing up when a i12345 (or whatever) is generated.

Use getConstantOperandVal/getConstantOperandAPInt wrappers where possible.

llvm-svn: 371315

[X86][AVX] Add 'f5' v4f64 shuffle test mentioned in D66004

llvm-svn: 371314

[mips] Make another set of test cases more tolerant to exact symbol addresses. NFC

llvm-svn: 371313

[ELF][MC] Set types of aliases of IFunc to STT_GNU_IFUNC

```
.type  foo,@gnu_indirect_function
.set   foo,foo_resolver

.set foo2,foo
.set foo3,foo2
```

The types of foo2 and foo3 should be STT_GNU_IFUNC, but we currently
resolve them to the type of foo_resolver. This patch fixes it.

Differential Revision: https://reviews.llvm.org/D67206
Patch by Senran Zhang

llvm-svn: 371312

[SimplifyCFG][NFC] Autogenerate PhiEliminate3.ll

llvm-svn: 371311

[SimplifyCFG][NFC] Autogenerate two tests

llvm-svn: 371310

[CodeGen] Handle SMULFIXSAT with scale zero in TargetLowering::expandFixedPointMul

Summary:
Normally TargetLowering::expandFixedPointMul would handle
SMULFIXSAT with scale zero by using an SMULO to compute the
product and determine if saturation is needed (if overflow
happened). But if SMULO isn't custom/legal it falls through
and uses the same technique, using MULHS/SMUL_LOHI, as used
for non-zero scales.

Problem was that when checking for overflow (handling saturation)
when not using MULO we did not expect to find a zero scale. So
we ended up in an assertion when doing
  APInt::getLowBitsSet(VTSize, Scale - 1)

This patch fixes the problem by adding a new special case for
how saturation is computed when scale is zero.

Reviewers: RKSimon, bevinh, leonardchan, spatel

Reviewed By: RKSimon

Subscribers: wuzish, nemanjai, hiraditya, MaskRay, jsji, llvm-commits

Tags: #llvm

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

llvm-svn: 371309

[Intrinsic] Add the llvm.umul.fix.sat intrinsic

Summary:
Add an intrinsic that takes 2 unsigned integers with
the scale of them provided as the third argument and
performs fixed point multiplication on them. The
result is saturated and clamped between the largest and
smallest representable values of the first 2 operands.

This is a part of implementing fixed point arithmetic
in clang where some of the more complex operations
will be implemented as intrinsics.

Patch by: leonardchan, bjope

Reviewers: RKSimon, craig.topper, bevinh, leonardchan, lebedev.ri, spatel

Reviewed By: leonardchan

Subscribers: ychen, wuzish, nemanjai, MaskRay, jsji, jdoerfert, Ka-Ka, hiraditya, rjmccall, llvm-commits

Tags: #llvm

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

llvm-svn: 371308

[X86] Fix pshuflw formation from repeated shuffle mask (PR43230)

Fix for https://bugs.llvm.org/show_bug.cgi?id=43230.

When creating PSHUFLW from a repeated shuffle mask, we have to apply
the checks to the repeated mask, not the original one. For the test
case from PR43230 the inspected part of the original mask is all undef.

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

llvm-svn: 371307

[LVI] Look through extractvalue of insertvalue

This addresses the issue mentioned on D19867. When we simplify
with.overflow instructions in CVP, we leave behind extractvalue
of insertvalue sequences that LVI no longer understands. This
means that we can not simplify any instructions based on the
with.overflow anymore (until some over pass like InstCombine
cleans them up).

This patch extends LVI extractvalue handling by calling
SimplifyExtractValueInst (which doesn't do anything more than
constant folding + looking through insertvalue) and using the block
value of the simplification.

A possible alternative would be to do something similar to
SimplifyIndVars, where we instead directly try to replace
extractvalue users of the with.overflow. This would need some
additional structural changes to CVP, as it's currently not legal
to remove anything but the current instruction -- we'd have to
introduce a worklist with instructions scheduled for deletion or similar.

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

llvm-svn: 371306

[X86] Add test for PR43230; NFC

llvm-svn: 371305

[DwarfExpression] Disallow some rewrites to avoid undefined behavior

Summary:
The value operand in DW_OP_plus_uconst/DW_OP_constu value can be
large (it uses uint64_t as representation internally in LLVM).
This means that in the uint64_t to int conversions, previously done
by DwarfExpression::addMachineRegExpression, could lose information.
Also, the negation done in "-Offset" was undefined behavior in case
Offset was exactly INT_MIN.

To avoid the above problems, we now avoid transformation like
 [Reg, DW_OP_plus_uconst, Offset] --> [DW_OP_breg, Offset]
and
 [Reg, DW_OP_constu, Offset, DW_OP_plus]  --> [DW_OP_breg, Offset]
when Offset > INT_MAX.

And we avoid to transform
 [Reg, DW_OP_constu, Offset, DW_OP_minus] --> [DW_OP_breg,-Offset]
when Offset > INT_MAX+1.

The patch also adjusts DwarfCompileUnit::constructVariableDIEImpl
to make sure that "DW_OP_constu, Offset, DW_OP_minus" is used
instead of "DW_OP_plus_uconst, Offset" when creating DIExpressions
with negative frame index offsets.

Notice that this might just be the tip of the iceberg. There
are lots of fishy handling related to these constants. I think both
DIExpression::appendOffset and DIExpression::extractIfOffset may
trigger undefined behavior for certain values.

Reviewers: sdesmalen, rnk, JDevlieghere

Reviewed By: JDevlieghere

Subscribers: jholewinski, aprantl, hiraditya, ychen, uabelho, llvm-commits

Tags: #debug-info, #llvm

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

llvm-svn: 371304

[DebugInfo] Pre-commit of test case for DW_OP_breg/DW_OP_fbreg folds

This currently triggers undefined behavior if executed with an
ubsan build. It is just a precommit of the test case to show that
we got a problem.

Fix is proposed in https://reviews.llvm.org/D67263 and plan is to
commit the fix directly after this patch.

llvm-svn: 371303

Fix MSVC "32-bit shift implicitly converted to 64 bits" warnings. NFCI.

llvm-svn: 371302

[SimplifyCFG][NFC] Make merge-cond-stores-cost.ll X86-specific, and rewrite it

We clearly perform store-merging, even though div is really costly.

llvm-svn: 371300

[ELF][test] Improve tests

Add file-level comments
Delete insignificant addresses to make them more tolerant to layout changes
Simplify test output

Delete weak-undef-val.s - covered by relocation-undefined-weak.s
Delete weak-undef-export.s - covered by additional test added to weak-undef.s
Delete version-undef-sym.s - covered by undefined-versioned-symbol.s => version-symbol-undef.s
Delete symbol-ordering-file2.s - covered by symbol-ordering-file.s
Delete gotpcrelx.s - covered by gotpc-relax-und-dso.s => x86-64-gotpc-relax-und-dso.s

llvm-svn: 371299

[Attributor] Make unimplemented method pure virtual.

Otherwise the compiler mistakes it for a vtable anchor.

llvm-svn: 371298

[SimplifyCFG][NFC] Show that we don't consider the cost when merging cond stores

We count instruction count in each BB's separately, not their cost.

llvm-svn: 371297

[SimplifyCFG][NFC] Regenerate merge-cond-stores* tests

llvm-svn: 371296

[SimplifyCFG] SpeculativelyExecuteBB(): It's SpeculatedInstructions, not SpeculationCost

It counts the number of instructions we are ok speculating
(at most 1 there), not their cost, so rename accordingly.

llvm-svn: 371294

Replicate the change "[Alignment][NFC] Use Align with TargetLowering::setMinFunctionAlignment"
on AVR to avoid a breakage.
See r371200 / https://reviews.llvm.org/D67229

llvm-svn: 371293

[ELF][test] Improve LTO tests

Add file-level comments
Delete insignificant addresses to make them more tolerant to layout changes
Simplify test output

llvm-svn: 371292

[Attributor] ValueSimplify Abstract Attribute

Summary:
This patch introduces initial `AAValueSimplify` which simplifies a value in a context.

example
- (for function returned) If all the return values are the same and constant, then we can replace callsite returned with the constant.
- If an internal function takes the same value(constant) as an argument in the callsite, then we can replace the argument with that constant.

Reviewers: jdoerfert, sstefan1

Reviewed By: jdoerfert

Subscribers: hiraditya, llvm-commits

Tags: #llvm

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

llvm-svn: 371291

[git-llvm] Do not reinvent `@{upstream}`

Make `git-llvm` more robust when used with a nontrivial repository.

https://reviews.llvm.org/D67262

llvm-svn: 371290

Revert [CodeGen] Fix typos to run tests. NFC.

This reverts r371286 (git commit b38105bbd0f7dfef424a4f096aa6a6b7b467fe99)

r371286 caused build bots' failure. I'll check it.

llvm-svn: 371289

[CodeGen] Fix typos to run tests. NFC.

llvm-svn: 371286

Remove stale TLI Module level pass registration

Clang patch to adapt to LLVM changes in D66428 that make the TLI
require a Function. There is no longer a module-level
TargetLibraryAnalysis, so remove its registration

llvm-svn: 371285

Change TargetLibraryInfo analysis passes to always require Function

Summary:
This is the first change to enable the TLI to be built per-function so
that -fno-builtin* handling can be migrated to use function attributes.
See discussion on D61634 for background. This is an enabler for fixing
handling of these options for LTO, for example.

This change should not affect behavior, as the provided function is not
yet used to build a specifically per-function TLI, but rather enables
that migration.

Most of the changes were very mechanical, e.g. passing a Function to the
legacy analysis pass's getTLI interface, or in Module level cases,
adding a callback. This is similar to the way the per-function TTI
analysis works.

There was one place where we were looking for builtins but not in the
context of a specific function. See FindCXAAtExit in
lib/Transforms/IPO/GlobalOpt.cpp. I'm somewhat concerned my workaround
could provide the wrong behavior in some corner cases. Suggestions
welcome.

Reviewers: chandlerc, hfinkel

Subscribers: arsenm, dschuff, jvesely, nhaehnle, mehdi_amini, javed.absar, sbc100, jgravelle-google, eraman, aheejin, steven_wu, george.burgess.iv, dexonsmith, jfb, asbirlea, gchatelet, llvm-commits

Tags: #llvm

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

llvm-svn: 371284

[X86] Add tests for fp128 frem, sqrt, sin, and cos.

llvm-svn: 371283

[X86] Autogenerate fp128-libcalls.ll

llvm-svn: 371282

[llvm-objcopy] Rename SHOffset (e_shoff) field to SHOff. NFC

Similar to D67254.

`struct Elf*_Shdr` has a field `sh_offset`. Rename SHOffset to SHOff to
avoid confusion.

llvm-svn: 371281

Long timeouts for the MacOSX SystemRuntime plugins under ASAN; else quick.

In April via r357829, Adrian unified timeouts across lldb and set the
default value high so that we wouldn't get timeouts on ASAN bots that
were running under load.

The library that the MacOSX SystemRuntime has functions that need
to take a lock, and if that lock is held already, those functions
will never complete; we're seeing the 15 second timeout being hit
with inferiors that are doing a lot of enqueuing and dequeuing of
libdispatch work items causing this deadlocking behavior.

This patch reverts to a very short timeout for these SystemRuntime
function calls, given the behavior of this library that they are
calling into.  When lldb is built with AddressSanitizer enabled,
they will use the default 15 second timeout.

tl;dr: this reverts to the previous timeouts for these SystemRuntime
inf func calls.

<rdar://problem/54538149>

llvm-svn: 371280

[clang][DependencyFileGenerator] Fix missing -MT option handling

Targets in DependencyFileGenerator don't necessarily come from -MT option.

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

llvm-svn: 371279

Fix thunks.cpp test, don't FileCheck for anon namespace id

The anon namespace id is a hash of the main input path to the compiler,
which varies in the test suite because the input path is absolute.

llvm-svn: 371277

[Sema][ObjC] Mark C union fields that have non-trivial ObjC ownership
qualifications as unavailable if the union is declared in a system
header

r365985 stopped marking those fields as unavailable, which caused the
union's NonTrivialToPrimitive* bits to be set to true. This patch
restores the behavior prior to r365985, except that users can explicitly
specify the ownership qualification of the field to instruct the
compiler not to mark it as unavailable.

rdar://problem/53420753

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

llvm-svn: 371276

[Sema] Diagnose default-initialization, destruction, and copying of
non-trivial C union types

This recommits r365985, which was reverted because it broke a few
projects using unions containing non-trivial ObjC pointer fields in
system headers. We now have a patch to fix the problem (see
https://reviews.llvm.org/D65256).

Original commit message:

This patch diagnoses uses of non-trivial C unions and structs/unions
containing non-trivial C unions in the following contexts, which require
default-initialization, destruction, or copying of the union objects,
instead of disallowing fields of non-trivial types in C unions, which is
what we currently do:

- function parameters.
- function returns.
- assignments.
- compound literals.
- block captures except capturing of `__block` variables by non-escaping blocks.
- local and global variable definitions.
- lvalue-to-rvalue conversions of volatile types.

See the discussion in https://reviews.llvm.org/D62988 for more background.

rdar://problem/50679094

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

llvm-svn: 371275

Synchronize LLVM's copy of libc++abi's demangler with the libc++abi
version after r371273.

Also fix a minor issue in r371273 that only surfaced after template
instantiation from LLVM's use of the demangler.

llvm-svn: 371274