TableGen/GlobalISel: Fix pattern matching of immarg literals

For arguments that are not expected to be materialized with
G_CONSTANT, this was emitting predicates which could never match. It
was firs

TableGen/GlobalISel: Fix pattern matching of immarg literals

For arguments that are not expected to be materialized with
G_CONSTANT, this was emitting predicates which could never match. It
was first adding a meaningless LLT check, which would always fail due
to the operand not being a register.

Infer the cases where a literal should check for an immediate operand,
instead of a register This avoids needing to invent a special way of
representing timm literal values.

Also handle immediate arguments in GIM_CheckLiteralInt. The comments
stated it handled isImm() and isCImm(), but that wasn't really true.

This unblocks work on the selection of all of the complicated AMDGPU
intrinsics in future commits.

show more ...

[NFC] Fix trivial typos in comments

Reviewed By: jhenderson

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

Patch by Kazuaki Ishizaki.

[TableGen] Remove unused target intrinsic generation logic

AMDGPU was the last in tree target to use this tablegen mode. I plan to
split up the global intrinsic enum similar to the way that clang
di

[TableGen] Remove unused target intrinsic generation logic

AMDGPU was the last in tree target to use this tablegen mode. I plan to
split up the global intrinsic enum similar to the way that clang
diagnostics are split up today. I don't plan to build on this mode.

Reviewers: arsenm, echristo, efriedma

Reviewed By: echristo

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

show more ...

[TableGen] Support encoding per-HwMode

Much like ValueTypeByHwMode/RegInfoByHwMode, this patch allows targets
to modify an instruction's encoding based on HwMode. When the
EncodingInfos field is non

[TableGen] Support encoding per-HwMode

Much like ValueTypeByHwMode/RegInfoByHwMode, this patch allows targets
to modify an instruction's encoding based on HwMode. When the
EncodingInfos field is non-empty the Inst and Size fields of the Instruction
are ignored and taken from EncodingInfos instead.

As part of this promote getHwMode() from TargetSubtargetInfo to MCSubtargetInfo.

This is NFC for all existing targets - new code is generated only if targets
use EncodingByHwMode.

llvm-svn: 372320

show more ...

[ValueTypes] Add v16f16 and v32f16 to EVT::getEVTString and Tablegen's getEnumName

Missed these when I hadded the enum entries

llvm-svn: 370494

Add tie-breaker for register class sorting in getSuperRegForSubReg

llvm::stable_sort is apparently not sufficient.

Use the same tie-breaker/sorting style as TopoOrderRC fix bot failures.

E.g.

htt

Add tie-breaker for register class sorting in getSuperRegForSubReg

llvm::stable_sort is apparently not sufficient.

Use the same tie-breaker/sorting style as TopoOrderRC fix bot failures.

E.g.

http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win/builds/19401/steps/test-check-all/logs/stdio

llvm-svn: 370267

show more ...

Recommit "[GlobalISel] Import patterns containing INSERT_SUBREG"

I thought `llvm::sort` was stable for some reason but it's not.

Use `llvm::stable_sort` in `CodeGenTarget::getSuperRegForSubReg`.

Recommit "[GlobalISel] Import patterns containing INSERT_SUBREG"

I thought `llvm::sort` was stable for some reason but it's not.

Use `llvm::stable_sort` in `CodeGenTarget::getSuperRegForSubReg`.

Original patch: https://reviews.llvm.org/D66498

llvm-svn: 370084

show more ...

Revert "[GlobalISel] Import patterns containing INSERT_SUBREG"

When EXPENSIVE_CHECKS are enabled, GlobalISelEmitterSubreg.td doesn't get
stable output.

Reverting while I debug it.

See: https://rev

Revert "[GlobalISel] Import patterns containing INSERT_SUBREG"

When EXPENSIVE_CHECKS are enabled, GlobalISelEmitterSubreg.td doesn't get
stable output.

Reverting while I debug it.

See: https://reviews.llvm.org/D66498
llvm-svn: 370080

show more ...

[GlobalISel] Import patterns containing INSERT_SUBREG

This teaches the importer to handle INSERT_SUBREG instructions.

We were missing patterns involving INSERT_SUBREG in AArch64. It appears in
AArc

[GlobalISel] Import patterns containing INSERT_SUBREG

This teaches the importer to handle INSERT_SUBREG instructions.

We were missing patterns involving INSERT_SUBREG in AArch64. It appears in
AArch64InstrInfo.td 107 times, and 14 times in AArch64InstrFormats.td.

To meaningfully import it, the GlobalISelEmitter needs to know how to infer a
super register class for a given register class.

This patch introduces the following:

- `getSuperRegForSubReg`, a function which finds the largest register class
which supports a value type and subregister index

- `inferSuperRegisterClass`, a function which finds the appropriate super
register class for an INSERT_SUBREG'

- `inferRegClassFromPattern`, a function which allows for some trivial
lookthrough into instructions

- `getRegClassFromLeaf`, a helper function which returns the register class for
a leaf `TreePatternNode`

- Support for subregister index operands in `importExplicitUseRenderer`

It also

- Updates tests in each backend which are impacted by the change

- Adds GlobalISelEmitterSubreg.td to test that we import and skip the expected
patterns

As a result of this patch, INSERT_SUBREG patterns in X86 may use the
LOW32_ADDR_ACCESS_RBP register class instead of GR32. This is correct, since the
register class contains the same registers as GR32 (except with the addition of
RBP). So, this also teaches X86 to handle that register class. This is in line
with X86ISelLowering, which treats this as a GR class.

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

llvm-svn: 369973

show more ...

Teach GlobalISelEmitter to treat used iPTRAny operands as pointer operands

Overloaded intrinsics can use iPTRAny in used/input operands.

The GlobalISelEmitter doesn't know that these are pointers,

Teach GlobalISelEmitter to treat used iPTRAny operands as pointer operands

Overloaded intrinsics can use iPTRAny in used/input operands.

The GlobalISelEmitter doesn't know that these are pointers, so it treats them
as scalars. As a result, these intrinsics can't be imported.

This teaches the GlobalISelEmitter to recognize these as pointers rather than
scalars.

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

llvm-svn: 369455

show more ...

MVT: Add v3i16/v3f16 vectors

AMDGPU has some buffer intrinsics which theoretically could use
this. Some of the generated tables include the 3 and 4 element vector
versions of these rounded to 64-bit

MVT: Add v3i16/v3f16 vectors

AMDGPU has some buffer intrinsics which theoretically could use
this. Some of the generated tables include the 3 and 4 element vector
versions of these rounded to 64-bits, which is ambiguous. Add these to
help the table disambiguate these.

Assertion change is for the path odd sized vectors now take for R600.
v3i16 is widened to v4i16, which then needs to be promoted to v4i32.

llvm-svn: 369038

show more ...

[llvm] Migrate llvm::make_unique to std::make_unique

Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
of

[llvm] Migrate llvm::make_unique to std::make_unique

Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
of (hopefully) all the llvm::make_unique instances across the monorepo.

llvm-svn: 369013

show more ...

[Intrinsics] Add a 'NoAlias' intrinsic property; annotate llvm.memcpy

Reviewers: jdoerfert

Reviewed By: jdoerfert

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

llvm-svn: 368810

[Attributor] Deduce "willreturn" function attribute

Summary:
Deduce the "willreturn" attribute for functions.

For now, intrinsics are not willreturn. More annotation will be done in another patch.

[Attributor] Deduce "willreturn" function attribute

Summary:
Deduce the "willreturn" attribute for functions.

For now, intrinsics are not willreturn. More annotation will be done in another patch.

Reviewers: jdoerfert

Subscribers: jvesely, nhaehnle, nicholas, hiraditya, llvm-commits

Tags: #llvm

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

llvm-svn: 366335

show more ...

[WebAssembly] Rename except_ref type to exnref

Summary:
We agreed to rename `except_ref` to `exnref` for consistency with other
reference types in
https://github.com/WebAssembly/exception-handling/i

[WebAssembly] Rename except_ref type to exnref

Summary:
We agreed to rename `except_ref` to `exnref` for consistency with other
reference types in
https://github.com/WebAssembly/exception-handling/issues/79. This also
renames WebAssemblyInstrExceptRef.td to WebAssemblyInstrRef.td in order
to use the file for other reference types in future.

Reviewers: dschuff

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

Tags: #llvm

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

llvm-svn: 366145

show more ...

[CodeGen] Add larger vector types for i32 and f32

Some out of tree backend require larger vector type. Since maintaining the changes out of tree is difficult due to the many manual changes needed wh

[CodeGen] Add larger vector types for i32 and f32

Some out of tree backend require larger vector type. Since maintaining the changes out of tree is difficult due to the many manual changes needed when adding a new type we are adding it even if no backend currently use it.

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

Patch by Thomas Raoux!

llvm-svn: 365274

show more ...

[IntrinsicEmitter] Extend argument overloading with forward references.

Extend the mechanism to overload intrinsic arguments by using either
backward or forward references to the overloadable argume

[IntrinsicEmitter] Extend argument overloading with forward references.

Extend the mechanism to overload intrinsic arguments by using either
backward or forward references to the overloadable arguments.

In for example:

def int_something : Intrinsic<[LLVMPointerToElt<0>],
[llvm_anyvector_ty], []>;

LLVMPointerToElt<0> is a forward reference to the overloadable operand
of type 'llvm_anyvector_ty' and would allow intrinsics such as:

declare i32* @llvm.something.v4i32(<4 x i32>);
declare i64* @llvm.something.v2i64(<2 x i64>);

where the result pointer type is deduced from the element type of the
first argument.

If the returned pointer is not a pointer to the element type, LLVM will
give an error:

Intrinsic has incorrect return type!
i64* (<4 x i32>)* @llvm.something.v4i32

Reviewers: RKSimon, arsenm, rnk, greened

Reviewed By: arsenm

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

llvm-svn: 363233

show more ...

[CodeGen] Defined MVTs v3i32, v3f32, v5i32, v5f32

AMDGPU would like to use these MVTs.

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

Change-Id: I6125fea810d7cc62a4b4de3d9904255a1233ae4e
l

[CodeGen] Defined MVTs v3i32, v3f32, v5i32, v5f32

AMDGPU would like to use these MVTs.

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

Change-Id: I6125fea810d7cc62a4b4de3d9904255a1233ae4e
llvm-svn: 356351

show more ...

IR: Add immarg attribute

This indicates an intrinsic parameter is required to be a constant,
and should not be replaced with a non-constant value.

Add the attribute to all AMDGPU and generic intrin

IR: Add immarg attribute

This indicates an intrinsic parameter is required to be a constant,
and should not be replaced with a non-constant value.

Add the attribute to all AMDGPU and generic intrinsics that comments
indicate it should apply to. I scanned other target intrinsics, but I
don't see any obvious comments indicating which arguments are intended
to be only immediates.

This breaks one questionable testcase for the autoupgrade. I'm unclear
on whether the autoupgrade is supposed to really handle declarations
which were never valid. The verifier fails because the attributes now
refer to a parameter past the end of the argument list.

llvm-svn: 355981

show more ...

[tablegen] Add locations to many PrintFatalError() calls

Summary:
While working on the GISel Combiner, I noticed I was producing location-less
error messages fairly often and set about fixing this.

[tablegen] Add locations to many PrintFatalError() calls

Summary:
While working on the GISel Combiner, I noticed I was producing location-less
error messages fairly often and set about fixing this. In the process, I
noticed quite a few places elsewhere in TableGen that also neglected to include
a relevant location.

This patch adds locations to errors that relate to a specific record (or a
field within it) and also have easy access to the relevant location. This is
particularly useful when multiclasses are involved as many of these errors
refer to the full name of a record and it's difficult to guess which substring
is grep-able.

Unfortunately, tablegen currently only supports Record granularity so it's not
currently possible to point at a specific Init so these sometimes point at the
record that caused the error rather than the precise origin of the error.

Reviewers: bogner, aditya_nandakumar, volkan, aemerson, paquette, nhaehnle

Reviewed By: nhaehnle

Subscribers: jdoerfert, nhaehnle, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, PkmX, jocewei, llvm-commits

Tags: #llvm

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

llvm-svn: 353862

show more ...

[tblgen] Add a timer covering the time spent reading the Instruction defs

This patch adds a -time-regions option to tablegen that can enable timers
(currently only one) that assess the performance o

[tblgen] Add a timer covering the time spent reading the Instruction defs

This patch adds a -time-regions option to tablegen that can enable timers
(currently only one) that assess the performance of tablegen itself. This
can be useful for identifying scaling problems with tablegen backends.

This particular timer has allowed me to ignore time that is not attributed
the GISel combiner pass. It's useful by itself but it is particularly
useful in combination with https://reviews.llvm.org/D52954 which causes
this period of time to be annotated within Xcode Instruments which in turn
allows profile samples and recorded allocations attributed to reading
instructions to be filtered out.

llvm-svn: 353763

show more ...

[IR] Match intrinsic parameter by scalar/vectorwidth

This patch replaces the existing LLVMVectorSameWidth matcher with LLVMScalarOrSameVectorWidth.

The matching args must be either scalars or vecto

[IR] Match intrinsic parameter by scalar/vectorwidth

This patch replaces the existing LLVMVectorSameWidth matcher with LLVMScalarOrSameVectorWidth.

The matching args must be either scalars or vectors with the same number of elements, but in either case the scalar/element type can differ, specified by LLVMScalarOrSameVectorWidth.

I've updated the _overflow intrinsics to demonstrate this - allowing it to return a i1 or <N x i1> overflow result, matching the scalar/vectorwidth of the other (add/sub/mul) result type.

The masked load/store/gather/scatter intrinsics have also been updated to use this, although as we specify the reference type to be llvm_anyvector_ty we guarantee the mask will be <N x i1> so no change in behaviour

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

llvm-svn: 351957

show more ...

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the ne

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636

show more ...

Mark @llvm.trap cold

A call to @llvm.trap can be expected to be cold (i.e. unlikely to be
reached in a normal program execution).

Outlining paths which unconditionally trap is an important memory
s

Mark @llvm.trap cold

A call to @llvm.trap can be expected to be cold (i.e. unlikely to be
reached in a normal program execution).

Outlining paths which unconditionally trap is an important memory
saving. As the hot/cold splitting pass (imho) should not treat all
noreturn calls as cold, explicitly mark @llvm.trap cold so that it can
be outlined.

Split out of https://reviews.llvm.org/D54244.

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

llvm-svn: 346885

show more ...

[MCSched] Bind PFM Counters to the CPUs instead of the SchedModel.

Summary:
The pfm counters are now in the ExegesisTarget rather than the
MCSchedModel (PR39165).

This also compresses the pfm count

[MCSched] Bind PFM Counters to the CPUs instead of the SchedModel.

Summary:
The pfm counters are now in the ExegesisTarget rather than the
MCSchedModel (PR39165).

This also compresses the pfm counter tables (PR37068).

Reviewers: RKSimon, gchatelet

Subscribers: mgrang, llvm-commits

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

llvm-svn: 345243

show more ...