[PATCH] D151088: [flang][hlfir] Separate -emit-fir and -emit-hlfir

2023-05-22 Thread Jean Perier via Phabricator via cfe-commits
jeanPerier accepted this revision. jeanPerier added a comment. This revision is now accepted and ready to land. Not the driver expert here, so please wait for @awarzynski input, but the new flag logic LGTM from a user point of view. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTI

[PATCH] D145815: [Flang][Driver] Add support for fopenmp-is-device and fembed-offload-object to Flang ToolChain

2023-03-29 Thread Jean Perier via Phabricator via cfe-commits
jeanPerier added a comment. > Hi @jeanPerier, > > Thank you! I noticed this today as well and I'm currently looking into it, i > have a fix upcoming, just forcing another patch > (https://reviews.llvm.org/D144896) to test it via buildbot as I have no easy > access to a windows machine to test

[PATCH] D145815: [Flang][Driver] Add support for fopenmp-is-device and fembed-offload-object to Flang ToolChain

2023-03-29 Thread Jean Perier via Phabricator via cfe-commits
jeanPerier added a comment. @agozillon, in the test added here (omp-frontend-forwarding.f90), I am seeing failures in some patches windows pre-merge checks that I think are not related to the patches. Could you check if there is a stability/reproducibility issue with the omp-frontend-forwarding

[PATCH] D140415: [flang] stack arrays pass

2023-02-07 Thread Jean Perier via Phabricator via cfe-commits
jeanPerier accepted this revision. jeanPerier added a comment. I do not have any further comments, thanks. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D140415/new/ https://reviews.llvm.org/D140415 ___ c

[PATCH] D140415: [flang] stack arrays pass

2023-01-25 Thread Jean Perier via Phabricator via cfe-commits
jeanPerier added a comment. Thanks for all the updates. This looks functionally correct to me. Since I am not very familiar with this kind of analysis and transformation, it would be great if another reviewer could give his/her opinion. But otherwise, given this solution is well isolated from a

[PATCH] D140415: [flang] stack arrays pass

2023-01-17 Thread Jean Perier via Phabricator via cfe-commits
jeanPerier added inline comments. Herald added a subscriber: sunshaoce. Comment at: flang/lib/Optimizer/Transforms/StackArrays.cpp:104 + + bool operator!=(const InsertionPoint &rhs) const { +return (location != rhs.location) || It's better to negate the `==

[PATCH] D130513: [Flang] Add -fconvert option to swap endianness for unformatted files

2022-10-04 Thread Jean Perier via Phabricator via cfe-commits
jeanPerier accepted this revision. jeanPerier added a comment. In D130513#3832241 , @jpenix-quic wrote: > Thank you @jeanPerier for looking over the lowering portion! Regarding moving > the header (I'm replying to the comment here since the inline one n

[PATCH] D130513: [Flang] Add -fconvert option to swap endianness for unformatted files

2022-09-30 Thread Jean Perier via Phabricator via cfe-commits
jeanPerier accepted this revision. jeanPerier added a comment. This revision is now accepted and ready to land. The lowering part looks good to me (I only have a minor comment inlined about a header used in lowering). Comment at: flang/include/flang/Runtime/environment-default

[PATCH] D107082: [X86][RFC] Enable `_Float16` type support on X86 following the psABI

2022-07-06 Thread Jean Perier via Phabricator via cfe-commits
jeanPerier added a comment. In D107082#3632301 , @pengfei wrote: > Hi @jeanPerier , yes, you are right. This patch changes the calling > conversion of fp16 from GPRs to XMMs. So you need to update the runtime. If > you are using compiler-rt, you could s

[PATCH] D107082: [X86][RFC] Enable `_Float16` type support on X86 following the psABI

2022-07-06 Thread Jean Perier via Phabricator via cfe-commits
jeanPerier added a comment. Hi @pengfei, I am working on flang, and after this patch, we started to see some bugs in Fortran programs using REAL(2) (which is fp16 in flang). I am not an expert in LLVM codegen and the builtins, but I am wondering if there is not issue with how llvm codegen think