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.

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

[pull] main from llvm:main #398

Merged
merged 28 commits into from
Dec 30, 2021
Merged

[pull] main from llvm:main #398

merged 28 commits into from
Dec 30, 2021

Conversation

pull[bot]
Copy link

@pull pull bot commented Dec 29, 2021

See Commits and Changes for more details.


Created by pull[bot]

Can you help keep this open source service alive? 💖 Please sponsor : )

…rameter packs

Otherwise these look a lot like actual templates (they have a name and
they have template parameters) but they don't participate in naming
(this doesn't come up in practice because a template parameter pack DIE
is never referenced from another DIE (so we don't do full name
rebuilding for it) or the subject of simplified template name rebuilding
(never has the _STN prefix)) - it could be tested with some hand crafted
DWARF but doesn't seem important/useful to do so.

This change is just for performance - to avoid trying to parse more
DIEs, etc, when it's not needed when computing the name in the DWARF
verifier.
@pull pull bot added the ⤵️ pull label Dec 29, 2021
joker-eph and others added 25 commits December 29, 2021 23:09
This is just fixing the build itself, the test won't pass right now.
The patterns of the immediate comparison instruction is rewrite here, and put similar code to a class.
Do not change any function of the original code, making the code more concise.

Reviewed By: craig.topper

Differential Revision: https://reviews.llvm.org/D116215
The run line of stack-protector-guard.c doesn't specify the triple,
which means it depends on the platform running the test. This makes
some failure hidden.

Reviewed By: nickdesaulniers

Differential Revision: https://reviews.llvm.org/D116003
…r is 0.

Use integer vector scalar move instruction when move 0 to avoid add a integer-float move instruction.

Differential Revision: https://reviews.llvm.org/D116365
…tt_found_proxy_tasks`

In most cases, hidden helper task behave similar as detached tasks. That means,
for example, if we have to wait for detached tasks, we have to do the same thing
for hidden helper tasks as well. This patch adds the missing condition for hidden
helper task accordingly along with detached task.

Reviewed By: AndreyChurbanov

Differential Revision: https://reviews.llvm.org/D107316
It is likely to become used again, if other projects want their own per-project
install directory variables. `install` is removed from the name since it is not inherently about installing.

Reviewed By: stephenneuendorffer

Differential Revision: https://reviews.llvm.org/D115746
There was one more reference the word "install" I forgot to remove.

Follow-up to bde561c /
https://reviews.llvm.org/D115746
The function `ConstantFoldCompareInstruction` uses `unsigned short` to
represent compare predicate, although all usesrs of the respective
include file use definition of CmpInst also. This change replaces
predicate argument type in this function to `ICmpInst::Predicate`,
which allows to make code a bit clearer and simpler.

No functional changes.

Differential Revision: https://reviews.llvm.org/D116379
Add missing coverage like .tdata/.data1/.rodata1
This reverts commit ada028c.

A performance regression was reported that we need to investigate:

#52919
The bitcode reader expected that the pointers are typed,
so that it can extract the function type for the assembly
so `bitc::CST_CODE_INLINEASM` did not explicitly store said function type.

I'm not really sure how the upgrade path will look for existing bitcode,
but i think we can easily support opaque pointers going forward,
by simply storing the function type.

Reviewed By: #opaque-pointers, nikic

Differential Revision: https://reviews.llvm.org/D116341
It was being used only in some very old tests (which pass even without
it) and its implementation is highly questionable.

These days we have different mechanisms for requesting a build with a
particular kind of c++ library (USE_LIB(STD)CPP in the makefile).
In D109958 it was noticed that we could optimise the pipeline and avoid
rerunning LoopSimplify/LCSSA for LoopFlatten by moving it to a LoopPassManager.

Differential Revision: https://reviews.llvm.org/D110057
This small patch adds two useful improvements:
- allows one to specify the emulator path as a bare filename, and have
  it be looked up in the PATH
- allows one to leave the path empty and have the filename be derived
  from the architecture.
…ice folding

vector.transfer operations do not have rank-reducing semantics.

Bail on illegal rank-reduction: we need to check that the rank-reduced
dims are exactly the leading dims. I.e. the following is illegal:
```
   %0 = vector.transfer_write %v, %t[0,0], %cst :
     vector<2x4xf32>, tensor<2x4xf32>
   %1 = tensor.insert_slice %0 into %tt[0,0,0][2,1,4][1,1,1] :
     tensor<2x4xf32> into tensor<2x1x4xf32>
```

Cannot fold into:
```
   %0 = vector.transfer_write %v, %t[0,0,0], %cst :
     vector<2x4xf32>, tensor<2x1x4xf32>
```
For this, check the trailing `vectorRank` dims of the insert_slice result
tensor match the trailing dims of the inferred result tensor.

Differential Revision: https://reviews.llvm.org/D116409
@devkadirselcuk devkadirselcuk merged commit 978ceb5 into turkdevops:main Dec 30, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment