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

Create mlir clang #224

Closed
wants to merge 1 commit into from
Closed

Create mlir clang #224

wants to merge 1 commit into from

Conversation

jeetgsoc
Copy link

mlir

@repo-lockdown
Copy link

repo-lockdown bot commented Jun 27, 2020

This repository does not accept pull requests. Please follow http://llvm.org/docs/Contributing.html#how-to-submit-a-patch for contribution to LLVM.

@repo-lockdown repo-lockdown bot closed this Jun 27, 2020
@repo-lockdown repo-lockdown bot locked and limited conversation to collaborators Jun 27, 2020
ghost referenced this pull request Jul 12, 2020
@EricWF @tstellar
[libc++] Fix recursive instantiation in std::array.
77d76b7 
The use of the `&& ...` fold expression in std::array's deduction guides
recursively builds a set of binary operator expressions of depth N where
`N` is the number of elements in the initializer.

This is problematic because arrays may be large, and instantiation
depth is limited.

This patch addresses the issue by flattening the SFINAE using
the existing `__all` type trait.

(cherry picked from commit c6eb584)
ghost referenced this pull request Jul 12, 2020
@tstellar
[DAGCombine] Check the uses of negated floating constant and remove t…
76ceebb 
…he hack

PowerPC hits an assertion due to somewhat the same reason as https://reviews.llvm.org/D70975.
Though there are already some hack, it still failed with some case, when the operand 0 is NOT
a const fp, it is another fma that with const fp. And that const fp is negated which result in multi-uses.

A better fix is to check the uses of the negated const fp. If there are already use of its negated
value, we will have benefit as no extra Node is added.

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

(cherry picked from commit 3906ae3)
ghost referenced this pull request Jul 12, 2020
@broadwaylamb @zmodem
[libcxx] Support Python 3.8 in the test suite
8dbe13f 
Summary: `platform.linux_distribution()` has been deprecated in Python 3.5 and removed in Python 3.8.

Reviewers: bcain, bcraig, jroelofs, EricWF, mclow.lists, ldionne

Reviewed By: jroelofs

Subscribers: dexonsmith, christof, ldionne, libcxx-commits

Tags: #libc

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

(cherry picked from commit 7b8dc8c)
ghost referenced this pull request Jul 12, 2020
@john-brawn-arm @zmodem
[FPEnv][ARM] Don't call mutateStrictFPToFP when lowering
f636e9f 
mutateStrictFPToFP can delete the node and replace it with another with the same
value which can later cause problems, and returning the result of
mutateStrictFPToFP doesn't work because SelectionDAGLegalize expects that the
returned value has the same number of results as the original. Instead handle
things by doing the mutation manually.

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

(cherry picked from commit 594a89f)
ghost referenced this pull request Jul 12, 2020
@zmodem
[AArch64][FPenv] Update chain of int to fp conversion
b5d9a7e 
Summary:
When using strict fp, it is required to update the
chain when performing integer type promotion of a
operand to a integer to floating point conversion.

Reviewers: craig.topper, john.brawn

Reviewed By: craig.topper

Subscribers: kristof.beyls, hiraditya, llvm-commits

Tags: #llvm

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

(cherry picked from commit 8bc790f)
ghost referenced this pull request Jul 12, 2020
@john-brawn-arm @zmodem
[ARM] Fix infinite loop when lowering STRICT_FP_EXTEND
cbac419 
If the target has FP64 but not FP16 then we have custom lowering for FP_EXTEND
and STRICT_FP_EXTEND with type f64. However if the extend is from f32 to f64 the
current implementation will cause in infinite loop for STRICT_FP_EXTEND due to
emitting a merge_values of the original node which after replacement becomes a
merge_values of itself.

Fix this by not doing anything for f32 to f64 extend when we have FP64, though
for STRICT_FP_EXTEND we have to do the strict-to-nonstrict mutation as that
doesn't happen automatically for opcodes with custom lowering.

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

(cherry picked from commit 0ec5797)
ghost referenced this pull request Jul 12, 2020
@john-brawn-arm @zmodem
[FPEnv][AArch64] Add lowering of f128 STRICT_FSETCC
cff417c 
These get lowered to function calls, like the non-strict versions.

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

(cherry picked from commit 68cf574)
lanza pushed a commit to lanza/llvm-project that referenced this pull request Feb 8, 2024
@sitio-couto @lanza
[CIR][CIRGen][Bugfix] Update unions to track all members
05a94f6 
This diverges from the original codegen by tracking all members of a
union, instead of just the largest one. This is necessary to support
type-checking at the MLIR level when accessing union members. It also
preserves more information about the source code, which might be useful.

Fixes llvm#224

ghstack-source-id: 8a975426d077a66c49f050741d7362da3c102fed
Pull Request resolved: llvm/clangir#229
pysuxing pushed a commit to pysuxing/llvm-project that referenced this pull request Jul 17, 2024
@sitio-couto @lanza
[CIR][CIRGen][Bugfix] Update unions to track all members
4198fa6 
This diverges from the original codegen by tracking all members of a
union, instead of just the largest one. This is necessary to support
type-checking at the MLIR level when accessing union members. It also
preserves more information about the source code, which might be useful.

Fixes llvm#224

ghstack-source-id: 8a975426d077a66c49f050741d7362da3c102fed
Pull Request resolved: llvm/clangir#229
pysuxing pushed a commit to pysuxing/llvm-project that referenced this pull request Jul 17, 2024
@sitio-couto @lanza
[CIR][CIRGen][Bugfix] Update unions to track all members
1f98396 
This diverges from the original codegen by tracking all members of a
union, instead of just the largest one. This is necessary to support
type-checking at the MLIR level when accessing union members. It also
preserves more information about the source code, which might be useful.

Fixes llvm#224

ghstack-source-id: 8a975426d077a66c49f050741d7362da3c102fed
Pull Request resolved: llvm/clangir#229
keryell pushed a commit to keryell/llvm-project that referenced this pull request Oct 19, 2024
@sitio-couto @lanza
[CIR][CIRGen][Bugfix] Update unions to track all members
fa6929f 
This diverges from the original codegen by tracking all members of a
union, instead of just the largest one. This is necessary to support
type-checking at the MLIR level when accessing union members. It also
preserves more information about the source code, which might be useful.

Fixes llvm#224

ghstack-source-id: 8a975426d077a66c49f050741d7362da3c102fed
Pull Request resolved: llvm/clangir#229
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
1 participant
@jeetgsoc