Strictly in a conversion operator's type, a <template-param> refers to a
<template-arg> that is further ahead in the mangled name. Instead of
doing a second parse to resolve these, introduce a
ForwardTemplateReference Node and back-patch the referenced
<template-arg> when we're in the right context.

This is also a correctness fix, previously we would only do a second
parse if the <template-param> was out of bounds in the current set of
<template-args>. This lead to misdemangles (gasp!) when the conversion
operator was a member of a templated struct, for instance.

llvm-svn: 328464

Rather than eagerly propagating up parameter pack sizes in Node ctors,
find the parameter pack size during printing. This is being done to
support back-patching forward referencing <template-param>s.

llvm-svn: 328463

Fixes PR33569.

llvm-svn: 328462

This continues the FP constant pattern matching improvements from:
https://reviews.llvm.org/rL327627
https://reviews.llvm.org/rL327339
https://reviews.llvm.org/rL327307

Several integer constant matchers also have this ability. I'm
separating matching of integer/pointer null from FP positive zero
and renaming/commenting to make the functionality clearer.

llvm-svn: 328461

llvm-svn: 328460

This patch throws a fatal error if an instregex entry doesn't actually match any instructions. This is part of the work to reduce the compile time impact of increased instregex usage (PR35955), although the x86 models seem to be relatively clean.

All the cases I encountered have now been fixed in trunk and this will ensure they don't get reintroduced.

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

llvm-svn: 328459

llvm-svn: 328458

Reviewed by @javed.absar

llvm-svn: 328457

llvm-svn: 328456

llvm-svn: 328455

[X86][SkylakeClient] Fix a set of regular expressions that were checking for optionally starting with 'Y' instead of 'V'

These bad regexs were introduced by r328435

llvm-svn: 328454

Not that it makes a difference to current cost values, but will when we try to better model GPR-SIMD transfer costs

llvm-svn: 328453

llvm-svn: 328452

Add fdiv costs for Goldmont using table 16-17 of the Intel Optimization Manual. Also add overrides for FSQRT for Goldmont and Silvermont.

Reviewers: RKSimon

Reviewed By: RKSimon

Subscribers: llvm-commits

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

llvm-svn: 328451

llvm-svn: 328450

We have thorough coverage of predicates and scalar types,
so we just need a sampling of vector tests to show that
things are working or not with vectors types.

llvm-svn: 328449

This is an extension of rL328426 as noted in D44367. 

llvm-svn: 328448

llvm-svn: 328447

[X86] Add the ability to override memory folding latency to schedules and add 1uop for memory folds for Intel models

The Intel models need an extra 1uop for memory folded instructions, plus a lot of instructions take a non-default memory latency which should allow us to use the multiclass a lot more to tidy things up.

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

llvm-svn: 328446

llvm-svn: 328445

llvm-svn: 328444

llvm-svn: 328443

llvm-svn: 328442

llvm-svn: 328441

We don't really care about the old vector value so we don't care to swap it.

llvm-svn: 328440

This patch removes the MachineValueType module since the
header was removed in r328395.

llvm-svn: 328439

[SchedModel] Remove std::vectors that were created with 1 element and then passed to an ArrayRef parameter.

ArrayRef can capture a single element. We don't need a vector for that.

llvm-svn: 328438

llvm-svn: 328437

[SchedModel] Avoid std::string creation for instregex patterns that don't contain regex metas. NFCI.

llvm-svn: 328436

[X86][SkylakeClient] Merge xmm/ymm instructions instregex entries to reduce regex matches to reduce compile time

llvm-svn: 328435

[X86][Broadwell] Merge xmm/ymm instructions instregex entries to reduce regex matches to reduce compile time

llvm-svn: 328434

Summary:
LLVM defaults to the newer .init_array/.fini_array scheme for static
constructors rather than the less desirable .ctors/.dtors (the UseCtors
flag defaults to false). This wasn't being respected in the RISC-V
backend because it fails to call TargetLoweringObjectFileELF::InitializeELF with the the appropriate
flag for UseInitArray.
This patch fixes this by implementing RISCVELFTargetObjectFile and overriding its Initialize method to call
InitializeELF(TM.Options.UseInitArray).

Reviewers: asb, apazos

Reviewed By: asb

Subscribers: mgorny, rbar, johnrusso, simoncook, jordy.potman.lists, sabuasal, niosHD, kito-cheng, shiva0217, llvm-commits

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

llvm-svn: 328433

[X86][Haswell] Merge xmm/ymm instructions instregex entries to reduce regex matches to reduce compile time

llvm-svn: 328432

[X86][SandyBridge] Merge xmm/ymm instructions instregex entries to reduce regex matches to reduce compile time

llvm-svn: 328431

Summary:
r327219 added wrappers to std::sort which randomly shuffle the container before sorting.
This will help in uncovering non-determinism caused due to undefined sorting
order of objects having the same key.

To make use of that infrastructure we need to invoke llvm::sort instead of std::sort.

Note: This patch is one of a series of patches to replace *all* std::sort to llvm::sort. Refer the comments section in D44363 for a list of all the required patches.

Reviewers: kparzysz

Reviewed By: kparzysz

Subscribers: llvm-commits

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

llvm-svn: 328430

Summary:
r327219 added wrappers to std::sort which randomly shuffle the container before sorting.
This will help in uncovering non-determinism caused due to undefined sorting
order of objects having the same key.

To make use of that infrastructure we need to invoke llvm::sort instead of std::sort.

Reviewers: tstellar, RKSimon, arsenm

Reviewed By: arsenm

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

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

llvm-svn: 328429

This also addresses Simon's review comment in D44839.

llvm-svn: 328428

llvm-svn: 328427

This pattern came up in PR36682:
https://bugs.llvm.org/show_bug.cgi?id=36682
https://godbolt.org/g/LhuD9A

Equality checks are planned as a follow-up enhancement.

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

llvm-svn: 328426

llvm-svn: 328425