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

We can revert region schedule if new schedule decreases occupancy.
However, if we already have only one wave we would accept any new
schedule even if it blows up register pressure. Such schedule may
result in quite heavy spilling which can be avoided if we reject
this new schedule.

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

It's not up to YAML to validate the semantics of the GDB remote packet
struct. This is especially wrong here as there's nothing that says that
the amount of bytes transmitted  matches the packet payload size.

Add two tests to reg-usage.ll

[mlir] Compilation fix: use LLVM_ATTRIBUTE_UNUSED following 6656e961

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

Summary: This fixes the return value of helper methods on the base range class.

Reviewed By: jpienaar

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

AMDGPU can't unambiguously go back from the selected instruction
register class to the register bank without knowing if this was used
in a boolean context.

This method allows getting the subprogram metadata object from a
function value.

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

Summary:
- CF users won't be non-instruction values. Skip them to save the
  compilation time. It's especially true when there are multiple
  functions in that module, where, says, a constant may be used in most
  functions. The current CF user tracing adds significant overhead.

Reviewers: alex-t, rampitec

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

Tags: #llvm

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

[clang-tidy] quickfix: add -fno-delayed-template-parsing as default argument for runCheckOnCode unit-tests to unbreak windows

-mpacked-stack is currently not supported with -mbackchain, so this should
result in a compilation error message instead of being silently ignored.

Review: Ulrich Weigand

There are some things that are shareable between the legalizer,
regbankselect, and the selector that don't have an obvious place to
go.

This would incorrectly allowing folding immediates. These currently
aren't selectable, but will be from GlobalISel soon.

Previously we only check that each field is of the correct
mlir::Attribute subclass. This commit enhances to also consider
the attribute's types, by leveraging the constraints already
encoded in TableGen attribute definitions.

Reviewed By: rsuderman

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

This fixes the error:
```
  mlir/include/mlir/Dialect/Linalg/Utils/Utils.h:72:3: error:   from definition of 'template<class LoopTy> mlir::edsc::GenericLoopNestRangeBuilder<LoopTy>::GenericLoopNestRangeBuilder(llvm::ArrayRef<mlir::edsc::ValueHandle*>, llvm::ArrayRef<mlir::Value>)' [-fpermissive]
    GenericLoopNestRangeBuilder(ArrayRef<edsc::ValueHandle *> ivs,
```

This was tested independently on a Docker image with gcc-5 by jpienaar@

SPIRV/ headers live under mlir/Dialect/.

Reviewed By: rriddle

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

See PR42982 for more context:
https://bugs.llvm.org/show_bug.cgi?id=42982

UpdateNodeOperands might CSE to another existing node. So we should make sure we're legalizing that node otherwise we might fail to hook up the operands properly. I've moved the result registration up to the caller to avoid having to pass both Result and Op into the functions where it might be confusing which is which.

This address 2 other issues pointed out in D71861.

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

This uses an alternative implementation of this conversion derived
from our v2i32->v2f32 handling. We can zero extend the v2i32 to
v2i64, or it with the bit representation of 2.0^52 which will give
us 2.0^52 plus the 32-bit integer since double's mantissa is 52 bits.
Then we just need to subtract 2.0^52 as a double and let the floating
point unit normalize the remaining bits into a valid double.

This is less instructions then our previous code, but does require
a port 5 shuffle for the zero extend or unpack.

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

Summary:
This patch extends the already existing facility to add 'const' to variables
to be more flexible and correct. The previous version did not consider pointers
as value AND pointee. For future automatic introduction for const-correctness
this shortcoming needs to be fixed.
It always allows configuration where the 'const' token is inserted, either on
the left side (if possible) or the right side.
It adds many unit-tests to the utility-function that did not exist before, as
the function was implicitly tested through clang-tidy checks. These
tests were not changed, as the API is still compatible.

Reviewers: aaron.ballman, hokein, alexfh, shuaiwang, lebedev.ri

Reviewed By: aaron.ballman

Subscribers: jdoerfert, mgorny, xazax.hun, cfe-commits

Tags: #clang

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

This should fix the error:
```
mlir/include/mlir/Dialect/Linalg/Utils/Utils.h:72:3: error:   from definition of 'template<class LoopTy> mlir::edsc::GenericLoopNestRangeBuilder<LoopTy>::GenericLoopNestRangeBuilder(llvm::ArrayRef<mlir::edsc::ValueHandle*>, llvm::ArrayRef<mlir::Value>)' [-fpermissive]
   GenericLoopNestRangeBuilder(ArrayRef<edsc::ValueHandle *> ivs,
```

When the "disable-tail-calls" attribute was added, checks were added for
it in various backends. Now this code has proliferated, and it is
something the target is responsible for checking. Move that
responsibility back to the ISels (fast, global, and SD).

There's no major functionality change, except for targets that never
implemented this check.

This LLVM attribute was originally added in
d9699bc7 (2015).

Reviewers: echristo, MaskRay

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

The patch files section is redundant to https://llvm.org/docs/GettingStarted.html.
There is nothing clang specific here. We are talking about a monorepo after all.
While it may seem nice to have one single clang page which explains everything,
it's not: It doesn't cover the topics in sufficient depth, it's redundant to
other pages and it's hard to keep it up to date as we see with the svn
instructions.

This decreases use count of Op1, potentially allows
us to further hoist said 'neg' later on,
and results in marginally better X86 codegen.

Name: (Op1 & С) - Op1 -> -(Op1 & ~C)
  %o = and i64 %Op1, C1
  %r = sub i64 %o, %Op1
=>
  %n = and i64 %Op1, ~C1
  %r = sub i64 0, %n

https://rise4fun.com/Alive/rwgA

https://godbolt.org/z/R_RMfM

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

Reviewers: nicolasvasilache

Reviewed By: nicolasvasilache

Subscribers: mgester, lucyrfox, merge_guards_bot, AlexEichenberger, mravishankar, ftynse, mehdi_amini, rriddle, jpienaar, burmako, shauheen, antiagainst, nicolasvasilache, arpith-jacob, llvm-commits

Tags: #llvm

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

When getting the file name form the line table prologue we assume that a
valid string form value can always be extracted as a string. If you look
at the implementation of DWARFormValue this is not necessarily true. I
hit this assertion from LLDB when I create a "dummy" DWARFContext that
was missing the string section.