RE: [RISC-V] Combining vfmv and .vv instructions into a .vf instruction

2024-07-24 Thread Demin Han
Hi, For this case: 1. last_combine1 the general pattern(plus (mult a b) c) can’t be combined. 2. last_bombine2 vec_duplicated is expanded to broadcast which can’t be handled by last_combine. For RVV, I think last_combine2 has no chance to combine anything because of fully expansion. Do I u

Re: Preparation for this weeks call

2024-07-24 Thread Thor Preimesberger via Gcc
Ah, thanks! I took a quick look today and I'll look more today. I should have a patch ready in about two weeks, but I'm gonna attach some notes and a link to the git repository I'm working on, in case anyone on the mailing list wants to take a look at it and provide feedback and/or request things

Re: Preparation for this weeks call

2024-07-24 Thread David Malcolm via Gcc
On Wed, 2024-07-24 at 02:59 -0500, Thor Preimesberger via Gcc wrote: > Sure - we actually already emit json in optinfo-emit-json.cc,  and > there > are implementations of json and pretty-printing/dumping it out also. > I got > a hacky version of our current raw dump working with json objects, > but

Re: [RISC-V] Combining vfmv and .vv instructions into a .vf instruction

2024-07-24 Thread 钟居哲
I think Demin is working on it. And Robin is reviewer of this stuff. juzhe.zh...@rivai.ai From: Artemiy Volkov Date: 2024-07-25 01:25 To: juzhe.zh...@rivai.ai; demin@starfivetech.com; jeffreya...@gmail.com CC: gcc@gcc.gnu.org Subject: [RISC-V] Combining vfmv and .vv instructions into a .vf

Re: [RISC-V] Combining vfmv and .vv instructions into a .vf instruction

2024-07-24 Thread Jeff Law via Gcc
On 7/24/24 11:25 AM, Artemiy Volkov wrote: Hi Juzhe, Demin, Jeff, This email is intended to continue the discussion started in https://marc.info/?l=gcc-patches&m=170927452922009&w=2 about combining vfmv.v.f and vfmxx.vv instructions into the scalar-vector form vfmxx.vf. There was a mention o

[RISC-V] Combining vfmv and .vv instructions into a .vf instruction

2024-07-24 Thread Artemiy Volkov via Gcc
Hi Juzhe, Demin, Jeff, This email is intended to continue the discussion started in https://marc.info/?l=gcc-patches&m=170927452922009&w=2 about combining vfmv.v.f and vfmxx.vv instructions into the scalar-vector form vfmxx.vf. There was a mention on that thread of the potential usefulness of the

Office Hours for the GNU Toolchain on 2024-07-25 at 11am EST5EDT.

2024-07-24 Thread Carlos O'Donell via Gcc
Office Hours for the GNU Toolchain on 2024-07-25 at 11am EST5EDT. Agenda: * https://gcc.gnu.org/wiki/OfficeHours#Next Meeting Link: * https://bbb.linuxfoundation.org/room/adm-xcb-for-sk6 -- Cheers, Carlos.

Re: Nonbootstrap build with Apple clang broken in gm2

2024-07-24 Thread FX Coudert via Gcc
> Ah yes indeed it is systematic. Many thanks for spotting this - git > pushed GNU flex required > https://gcc.gnu.org/pipermail/gcc-cvs/2024-July/406305.html Couldn’t the generated files be committed to the tree, so that flex is not needed (unless one modifies the source). This is what is done

Re: Nonbootstrap build with Apple clang broken in gm2

2024-07-24 Thread Gaius Mulley via Gcc
FX Coudert writes: > Another quick m2-related question: I am seeing, in a build of GCC > 14.1.0 on Linux, that flex is called when building with the modula-2 > front-end. It was not the case in previous builds, and the only > difference is that I added m2 to the languages. Is that systematic? If

Re: Preparation for this weeks call

2024-07-24 Thread Richard Biener via Gcc
On Wed, Jul 24, 2024 at 9:59 AM Thor Preimesberger wrote: > > Sure - we actually already emit json in optinfo-emit-json.cc, and there are > implementations of json and pretty-printing/dumping it out also. I got a > hacky version of our current raw dump working with json objects, but using > th

Re: why are these std::set iterators of different type when compiling with -D_GLIBCXX_DEBUG

2024-07-24 Thread Dennis Luehring via Gcc
Am 24.07.2024 um 12:41 schrieb Jonathan Wakely: The standard says it's unspecified whether those types are the same, so portable code should not assume they are/aren't the same. I don't know for sure, but I assume somebody thought that making them different was helpful to avoid non-portable code.

Re: why are these std::set iterators of different type when compiling with -D_GLIBCXX_DEBUG

2024-07-24 Thread Jonathan Wakely via Gcc
On Wed, 24 Jul 2024 at 11:38, Dennis Luehring via Gcc wrote: > > using latest gcc/STL > > - > #include > > using int_set1 = std::set>; > using int_set2 = std::set; > > static_assert(std::is_same()); > - > > > the two iterators are equal when not using _GLIBCXX_DEBUG but become > d

why are these std::set iterators of different type when compiling with -D_GLIBCXX_DEBUG

2024-07-24 Thread Dennis Luehring via Gcc
using latest gcc/STL - #include using int_set1 = std::set>; using int_set2 = std::set; static_assert(std::is_same()); - the two iterators are equal when not using _GLIBCXX_DEBUG but become different when using the define?

Re: How to implement Native TLS for a specific platform?

2024-07-24 Thread Claudiu Zissulescu Ianculescu via Gcc
Hi Julian, I hope you have Ulrich's document about TLS, if not please google it: "ELF Handling for Thread-Local Storage - Ulrich Drepper" In ARC, I used unspec constructions to emit TLS addresses. If you wanna simplify it, in the legitimzie_tls_address you can only implement the most general case

Re: Preparation for this weeks call

2024-07-24 Thread Thor Preimesberger via Gcc
Sure - we actually already emit json in optinfo-emit-json.cc, and there are implementations of json and pretty-printing/dumping it out also. I got a hacky version of our current raw dump working with json objects, but using the functions and data structures in tree-dump.* "as is" would require fur