Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[pull] master from llvm:master #512

Merged
merged 4 commits into from
Sep 22, 2019
Merged

[pull] master from llvm:master #512

merged 4 commits into from
Sep 22, 2019

Commits on Sep 22, 2019

  1. [clang] fixing conditional explicit for out-of-line definition PR42980 

    Summary: not every read in CXXConstructorDecl::getExplicitSpecifierInternal() was made on the canonical declaration.

Reviewers: rsmith, aaron.ballman

Reviewed By: rsmith

Subscribers: cfe-commits

Tags: #clang

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

llvm-svn: 372530
    @Ralender
    Ralender committed Sep 22, 2019
    Configuration menu
    Copy the full SHA
    914c4c3 View commit details
    Browse the repository at this point in the history

  2. [Diagnostics] Warn if ?: with integer constants always evaluates to true 

    Extracted from D63082. GCC has this warning under -Wint-in-bool-context, but as noted in the D63082's review, we should put it under TautologicalConstantCompare.

llvm-svn: 372531
    @davidbolvansky
    davidbolvansky committed Sep 22, 2019
    Configuration menu
    Copy the full SHA
    fb21817 View commit details
    Browse the repository at this point in the history

  3. [X86] X86DAGToDAGISel::matchBEXTRFromAndImm(): if can't use BEXTR, fa… 

    …llback to BZHI is profitable (PR43381)

Summary:
PR43381 notes that while we are good at matching `(X >> C1) & C2` as BEXTR/BEXTRI,
we only do that if we either have BEXTRI (TBM),
or if BEXTR is marked as being fast (`-mattr=+fast-bextr`).
In all other cases we don't match.

But that is mainly only true for AMD CPU's.
However, for all the CPU's for which we have sched models,
the BZHI is always fast (or the sched models are all bad.)

So if we decide that it's unprofitable to emit BEXTR/BEXTRI,
we should consider falling-back to BZHI if it is available,
and follow-up with the shift.

While it's really tempting to do something because it's cool
it is wise to first think whether it actually makes sense to do.
We shouldn't just use BZHI because we can, but only it it is beneficial.
In particular, it isn't really worth it if the input is a register,
mask is small, or we can fold a load.
But it is worth it if the mask does not fit into 32-bits.

(careful, i don't know much about intel cpu's, my choice of `-mcpu` may be bad here)
Thus we manage to fold a load:
https://godbolt.org/z/Er0OQz
Or if we'd end up using BZHI anyways because the mask is large:
https://godbolt.org/z/dBJ_5h
But this isn'r actually profitable in general case,
e.g. here we'd increase microop count
(the register renaming is free, mca does not model that there it seems)
https://godbolt.org/z/k6wFoz
Likewise, not worth it if we just get load folding:
https://godbolt.org/z/1M1deG

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

Reviewers: RKSimon, craig.topper, davezarzycki, spatel

Reviewed By: craig.topper, davezarzycki

Subscribers: andreadb, hiraditya, llvm-commits

Tags: #llvm

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

llvm-svn: 372532
    @LebedevRI
    LebedevRI committed Sep 22, 2019
    Configuration menu
    Copy the full SHA
    7c3d6f5 View commit details
    Browse the repository at this point in the history

  4. [NFC] Fixed failed test 

    llvm-svn: 372533
    @davidbolvansky
    davidbolvansky committed Sep 22, 2019
    Configuration menu
    Copy the full SHA
    7b4d40e View commit details
    Browse the repository at this point in the history