llvm-svn: 374059

Summary:
This format introduces new features and platforms
The motivation for this format is to support more than 1 platform since previous versions only supported additional architectures and 1 platform,
for example ios + ios-simulator and macCatalyst.

Reviewers: ributzka, steven_wu

Reviewed By: ributzka

Subscribers: mgorny, hiraditya, mgrang, dexonsmith, llvm-commits

Tags: #llvm

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

llvm-svn: 374058

C linkage.

After some discussion with OpenMP developers, it was decided that the
functions with the different C linkage can be used in declare variant
directive.

llvm-svn: 374057

We tried doing that previously (in r373487) and failed (reverted in
r373506) because the benchmarks needed to link against system libraries
and relied on libc++'s dependencies being propagated. Now that this has
been fixed (in r374053), this commit marks the system libraries as
PRIVATE dependencies of libc++.

llvm-svn: 374056

When -pg option is present than a call to _mcount is inserted into every
function. However since the proper ABI was not followed then the generated
gmon.out did not give proper results. By inserting needed instructions 
before every _mcount we can fix this.

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

llvm-svn: 374055

Summary:
This adds a `-max-configs-per-opcode` option to limit the number of
configs per opcode.

Reviewers: gchatelet

Subscribers: tschuett, llvm-commits

Tags: #llvm

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

llvm-svn: 374054

Since the benchmarks build with -nostdlib, they need to manually link
against some system libraries that are used by the benchmarks and the
GoogleBenchmark library itself.

Previously, we'd rely on the fact that these libraries were linked
through the PUBLIC dependencies of cxx_shared/cxx_static. However,
if we were to make these dependencies PRIVATE (as they should be
because they are implementation details of libc++), the benchmarks
would fail to link. This commit remediates that.

llvm-svn: 374053

These are sometimes generated by tail call optimizations.

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

llvm-svn: 374052

Summary:
This patch adds the definitions of the constants and structures
necessary to interpret the MemoryInfoList minidump stream, as well as
the object::MinidumpFile interface to access the stream.

While the code is fairly simple, there is one important deviation from
the other minidump streams, which is worth calling out explicitly.
Unlike other "List" streams, the size of the records inside
MemoryInfoList stream is not known statically. Instead it is described
in the stream header. This makes it impossible to return
ArrayRef<MemoryInfo> from the accessor method, as it is done with other
streams. Instead, I create an iterator class, which can be parameterized
by the runtime size of the structure, and return
iterator_range<iterator> instead.

Reviewers: amccarth, jhenderson, clayborg

Subscribers: JosephTremoulet, zturner, markmentovai, lldb-commits, llvm-commits

Tags: #llvm

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

llvm-svn: 374051

It's better style to use PRIVATE when linking libraries to executables,
and it doesn't make a difference since executables don't need to propagate
their link-time dependencies anyway.

llvm-svn: 374050

it just happened to break the bot right when I did my push. So I'm undoing
this mornings incorrect push. I've also kicked off an email to hopefully
get the bot fixed the correct way.

llvm-svn: 374049

Summary: Applying it produces incorrect code at the moment.

Reviewers: sammccall

Reviewed By: sammccall

Subscribers: kuhnel, MaskRay, jkorous, arphaman, kadircet, usaxena95, cfe-commits

Tags: #clang

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

llvm-svn: 374048

llvm-svn: 374047

On my system, llvm-objcopy was refusing to remove the .dynsym section
because it was still referenced from .rela.plt. Remove that section too,
and clarify that this is needed only because llvm-objcopy
--only-keep-debug does not work (does not set the sections to
SHT_NOBITS). Also, ensure that the test is not creating temporary files
in the source tree.

llvm-svn: 374046

llvm-svn: 374045

Tim Northover remarked that the added patterns for fmls fp16
produce wrong code in case the fsub instruction has a
multiplication as its first operand, i.e., all the patterns FMLSv*_OP1:

> define <8 x half> @test_FMLSv8f16_OP1(<8 x half> %a, <8 x half> %b, <8 x half> %c) {
> ; CHECK-LABEL: test_FMLSv8f16_OP1:
> ; CHECK: fmls {{v[0-9]+}}.8h, {{v[0-9]+}}.8h, {{v[0-9]+}}.8h
> entry:
>
>   %mul = fmul fast <8 x half> %c, %b
>   %sub = fsub fast <8 x half> %mul, %a
>   ret <8 x half> %sub
> }
>
> This doesn't look right to me. The exact instruction produced is "fmls
> v0.8h, v2.8h, v1.8h", which I think calculates "v0 - v2*v1", but the
> IR is calculating "v2*v1-v0". The equivalent <4 x float> code also
> doesn't emit an fmls.

This patch generates an fmla and negates the value of the operand2 of the fsub.

Inspecting the pattern match, I found that there was another mistake in the
opcode to be selected: matching FMULv4*16 should generate FMLSv4*16
and not FMLSv2*32.

Tested on aarch64-linux with make check-all.

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

llvm-svn: 374044

llvm-svn: 374043

* Adds a TypeSize struct to represent the known minimum size of a type
  along with a flag to indicate that the runtime size is a integer multiple
  of that size
* Converts existing size query functions from Type.h and DataLayout.h to
  return a TypeSize result
* Adds convenience methods (including a transparent conversion operator
  to uint64_t) so that most existing code 'just works' as if the return
  values were still scalars.
* Uses the new size queries along with ElementCount to ensure that all
  supported instructions used with scalable vectors can be constructed
  in IR.

Reviewers: hfinkel, lattner, rkruppe, greened, rovka, rengolin, sdesmalen

Reviewed By: rovka, sdesmalen

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

llvm-svn: 374042

Summary: Issue: https://github.com/GPUOpen-Drivers/llpc/issues/204

Reviewers: arsenm, rampitec

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

Tags: #llvm

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

llvm-svn: 374041

Summary:
When getValueInMiddleOfBlock happens to be called for a basic block
that has no incoming value at all, an IMPLICIT_DEF is inserted in that
block via GetValueAtEndOfBlockInternal. This IMPLICIT_DEF must be at
the top of its basic block or it will likely not reach the use that
the caller intends to insert.

Issue: https://github.com/GPUOpen-Drivers/llpc/issues/204

Reviewers: arsenm, rampitec

Subscribers: jvesely, wdng, hiraditya, llvm-commits

Tags: #llvm

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

llvm-svn: 374040

llvm-svn: 374039

Patch by jbeich (Jan Beich)

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

llvm-svn: 374038

Patch by jbeich (Jan Beich)

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

llvm-svn: 374037

LoopRotate is a loop pass and the DomTree should always be available.

Similar to a70c5261

llvm-svn: 374036

Summary:
Character buffers are sometimes used to represent a pool of memory that
contains non-character objects, due to them being synonymous with a stream of
bytes on almost all modern architectures. Often, when interacting with hardware
devices, byte buffers are therefore used as an intermediary and so we can end
Character buffers are sometimes used to represent a pool of memory that
contains non-character objects, due to them being synonymous with a stream of
bytes on almost all modern architectures. Often, when interacting with hardware
devices, byte buffers are therefore used as an intermediary and so we can end
up generating lots of false-positives.

Moreover, due to the ability of character pointers to alias non-character
pointers, the strict aliasing violations that would generally be implied by the
calculations caught by the warning (if the calculation itself is in fact
correct) do not apply here, and so although the length calculation may be
wrong, that is the only possible issue.

Reviewers: rsmith, xbolva00, thakis

Reviewed By: xbolva00, thakis

Subscribers: thakis, lebedev.ri, cfe-commits

Tags: #clang

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

llvm-svn: 374035

Before this patch, loads and stores were only tracked by their corresponding
queues in the LSUnit from dispatch until execute stage. In practice we should be
more conservative and assume that memory opcodes leave their queues at
retirement stage.

Basically, loads should leave the load queue only when they have completed and
delivered their data. We conservatively assume that a load is completed when it
is retired. Stores should be tracked by the store queue from dispatch until
retirement. In practice, stores can only leave the store queue if their data can
be written to the data cache.

This is mostly a mechanical change. With this patch, the retire stage notifies
the LSUnit when a memory instruction is retired. That would triggers the release
of LDQ/STQ entries.  The only visible change is in memory tests for the bdver2
model. That is because bdver2 is the only model that defines the load/store
queue size.

This patch partially addresses PR39830.

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

llvm-svn: 374034

Support for tracking registers that forward function parameters into the
following function frame. For now we only support cases when parameter
is forwarded through single register.

Reviewers: aprantl, vsk, t.p.northover

Reviewed By: vsk

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

llvm-svn: 374033

https://llvm.org/reports/scan-build/report-TargetInfo.cpp-detectFPCCEligibleStruct-9-1.html#EndPath

llvm-svn: 374032

Summary:
Right now there are no snippet generators that emit the `Config` Field,
but I plan to add it to investigate LEA operands for PR32326.

What was broken was:
 - `Config` Was not propagated up until the BenchmarkResult::Key.
 - Clustering should really consider different configs as measuring
 different things, so we should stabilize on (Opcode, Config) instead of
 just Opcode.

Reviewers: gchatelet

Subscribers: tschuett, llvm-commits, lebedev.ri

Tags: #llvm

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

llvm-svn: 374031

This reverts r373758 because it causes several to test to be flaky (=
failing ~90% of the time) on linux.

llvm-svn: 374030

namespace-closing '}' don't need ';'.

llvm-svn: 374029

We do not check the GNU-style output when -all is given.
This patch does that.

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

llvm-svn: 374028

llvm-svn: 374027

Summary: LoopRotate is a loop pass and SE should always be available.

Reviewers: anemet, asbirlea

Reviewed By: asbirlea

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

llvm-svn: 374026

Based on the discussion in
http://lists.llvm.org/pipermail/llvm-dev/2019-October/135574.html, the
conclusion was reached that the ARM backend should produce vcmp instead
of vcmpe instructions by default, i.e. not be producing an Invalid
Operation exception when either arguments in a floating point compare
are quiet NaNs.

In the future, after constrained floating point intrinsics for floating
point compare have been introduced, vcmpe instructions probably should
be produced for those intrinsics - depending on the exact semantics
they'll be defined to have.

This patch logically consists of the following parts:
- Revert http://llvm.org/viewvc/llvm-project?rev=294945&view=rev and
  http://llvm.org/viewvc/llvm-project?rev=294968&view=rev, which
  implemented fine-tuning for when to produce vcmpe (i.e. not do it for
  equality comparisons). The complexity introduced by those patches
  isn't needed anymore if we just always produce vcmp instead. Maybe
  these patches need to be reintroduced again once support is needed to
  map potential LLVM-IR constrained floating point compare intrinsics to
  the ARM instruction set.
- Simply select vcmp, instead of vcmpe, see simple changes in
  lib/Target/ARM/ARMInstrVFP.td
- Adapt lots of tests that tested for vcmpe (instead of vcmp). For all
  of these test, the intent of what is tested for isn't related to
  whether the vcmp should produce an Invalid Operation exception or not.

Fixes PR43374.

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

llvm-svn: 374025

Several LLVM tools write text files/streams without using OF_Text.
This can cause problems on platforms which distinguish between
text and binary output. This PR adds the OF_Text flag for the
following tools:

- llvm-dis
- llvm-dwarfdump
- llvm-mca
- llvm-mc (assembler files only)
- opt (assembler files only)
- RemarkStreamer (used e.g. by opt)

Reviewers: rnk, vivekvpandya, Bigcheese, andreadb

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

llvm-svn: 374024

llvm-svn: 374023

The combination of the two flags doesn't make sense. And other linkers
seem to just ignore --export-dynamic if --relocatable is given, but
we probably should report it as an error to let users know that is
an invalid combination.

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

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

llvm-svn: 374022

llvm-svn: 374021

In preparation for D68629.

llvm-svn: 374020