We unconditionally marked i64 as Custom, but did not install a
handler in ReplaceNodeResults when i64 isn't legal type. This
leads to ReplaceNodeResults asserting.

We have two options to fix this. Only mark i64 as Custom on
64-bit targets and let it expand to two i32 bitreverses which
each need a VPPERM. Or the other option is to add the Custom
handling to ReplaceNodeResults. This is what I went with.

In the last change to IRCE the BPI is ignored if BFI is present, however
BFI and BPI have a different thresholds. Specifically BPI approach checks only
latch exit probability so it is expected if the loop has only one exit block (latch)
the behavior with BFI and BPI should be the same,

BPI approach by default uses threshold 10, so it considers the loop with estimated
number of iterations less then 10 should not be considered for IRCE optimization.
BFI approach uses the default value 3 and this is inconsistent.

The CL modifies the code to use the same threshold for both approaches..

The test is updated due to it has two side-exits (except latch) and each of them has a
probability 1/16, so BFI estimates the number of runtime iteration is about to 7
(1/16 + 1/16 + some for latch) and test fails.

Reviewers: mkazantsev, ebrevnov
Reviewed By: mkazantsev
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D91230

I had manually removed unused prefixes from CodeGen/X86 directory for more than 100 tests.
I checked the change history for each of them at the beginning, and then I mainly focused on the format since I found all of the unused prefixes were result from either insensible copy or residuum after functional update.
I think it's OK to remove the remaining X86 tests by script now. I wrote a rough script which works for me in most tests. I put it in llvm/utils temporarily for review and hope it may help other components owners.
The tests in this patch are all generated by the tool and checked by update tool for the autogenerated tests. I skimmed them and checked about 30 tests and didn't find any unexpected changes.

Reviewed By: mtrofin, MaskRay

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

parameters.

It appears that LLVM isn't able to generate a DW_AT_const_value for a
constant of class type, but if it could, we'd match GCC's debug info in
this case, and in the interim we no longer crash.

There are 1-2 potential follow-up NFC commits to reduce
this further on the way to generalizing this for vectors.

The operand replacing path should be dead code because demanded
bits handles that more generally (D91415).

I noticed an add example like the one from D91343, so here's a similar patch.
The logic is based on existing code for the single-use demanded bits fold.
But I only matched a constant instead of using compute known bits on the
operands because that was the motivating patterni that I noticed.

I think this will allow removing a special-case (but incomplete) dedicated
fold within visitAnd(), but I need to untangle the existing code to be sure.

https://rise4fun.com/Alive/V6fP

  Name: add with low mask
  Pre: (C1 & (-1 u>> countLeadingZeros(C2))) == 0
  %a = add i8 %x, C1
  %r = and i8 %a, C2
  =>
  %r = and i8 %x, C2

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

See D91415.

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

This alias() call did not pass on the AAQueryInfo.

Reviewed here: https://reviews.llvm.org/D91409 by Aaron.
Highlights of the review:
  - avoid an underlying type for enums
  - avoid enum bit fields (MSVC packing anomalies) and favor static_casts to unsigned bit-fields

Patch by Thorsten Schuett <schuett@gmail.com> w some minor fixes in SemaType.cpp where a couple asserts had to be repaired to deal with lack of implicit coversion to int.

Thanks Thorsten!

As Richard Smith pointed out in the review of D90123, both the C and C++
standard call it lvalue and rvalue, so let's stick to the same spelling
in Clang.

When an overloaded member function has a ref-qualifier, like:

class X {
    void f() &&;
    void f(int) &;
};

we would print strange notes when the ref-qualifier doesn't fit the value
category:

X x;
x.f();
X().f(0);

would both print a note "no known conversion from 'X' to 'X' for object
argument" on their relevant overload instead of pointing out the
mismatch in value category.

At first I thought the solution is easy: just use the FailureKind member
of the BadConversionSequence struct. But it turns out that we weren't
properly setting this for function arguments. So I went through
TryReferenceInit to make sure we're doing that right, and found a number
of notes in the existing tests that improved as well.

Fixes PR47791.

Reviewed By: rsmith

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

This patch turns VPWidenGEPRecipe into a VPValue and uses it
during VPlan construction and codegeneration instead of the plain IR
reference where possible.

Reviewed By: dmgreen

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

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

Bound arch may contain ':', which is invalid in Windows file names.

This patch fixes that.

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

We are only checking for the class type. Fixes Wshadow warnings.

Reviewed By: ftynse, mehdi_amini

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

This reverts commit 1ec6e1eb.

This change causes a significant compile-time regression:
https://llvm-compile-time-tracker.com/compare.php?from=dd0b8b94d0796bd895cc998dd163b4fbebceb0b8&to=1ec6e1eb8a084bffae8a40236eb9925d8026dd07&stat=instructions

I assume that this is due to the non-NFC part of the change, which
now performs expensive nowrap inference even for nowrap flags that
are not used by the particular code.

In an effort to make code around flag determination more readable, and (possibly) prepare for a follow up change, factor out some of the flag detection logic.  In the process, reduce the number of locations we mutate wrap flags by a couple.

Note that this isn't NFC.  The old code tried for NSW xor (NUW || NW).  This is, two different paths computed different sets of wrap flags.  The new code will try for all three.  The result is that some expressions end up with a few extra flags set.

This is used to test RemoveRedundantDbgInstrs(), which is used by other
passes.

Reviewed By: ychen

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

This patch reduces the copy paste in the unittest/CodeGen folder by moving the
common compiler setup phase in a header file.

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

This reverts the revert commit c8d73d93.

It includes a fix for cases where we missed inserting VPValues
for some selects, which should fix PR48142.

Also follows what we do in std ops too and move it before :.

9218ff50 removed the BUILD.txt file, and as a subtle side-effect
libLLVMFrontendOpenACC wasn't a dependency of `ninja check` anymore.
However llvm-config requires all components to be built, and the
relevant test is broken when libLLVMFrontendOpenACC isn't built.

Unittest for libLLVMFrontendOpenACC are pending, but this addition
should fix some bots in the meantime.

We're dropping a common offset from both GEPs here. It's not
necessary for the access sizes to be the same as well.