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

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

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

llvm-svn: 371323

llvm-svn: 371322

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 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

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

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

llvm-svn: 371317

llvm-svn: 371316

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

llvm-svn: 371314

llvm-svn: 371313

```
.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

llvm-svn: 371311

llvm-svn: 371310

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

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

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

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

llvm-svn: 371305

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

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

llvm-svn: 371302

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

llvm-svn: 371300

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

Otherwise the compiler mistakes it for a vtable anchor.

llvm-svn: 371298

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

llvm-svn: 371297

llvm-svn: 371296

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

llvm-svn: 371294

on AVR to avoid a breakage.
See r371200 / https://reviews.llvm.org/D67229

llvm-svn: 371293

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

llvm-svn: 371292

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

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

https://reviews.llvm.org/D67262

llvm-svn: 371290

This reverts r371286 (git commit b38105bb)

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

llvm-svn: 371289

llvm-svn: 371286

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

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

llvm-svn: 371283