Re: How to extend SLP to support this case

Hi Richi, on 2020/3/10 下午7:12, Richard Biener wrote: > On Tue, Mar 10, 2020 at 7:52 AM Kewen.Lin wrote: >> >> Hi all, >> >> But how to teach it to be aware of this? Currently the processing starts >> from bottom to up (from stores), can we do some analysis on the SLP >> instance, detect some patt

Re: How to extend SLP to support this case

Hi Tamar, on 2020/3/10 下午7:31, Tamar Christina wrote: > >> -Original Message- >> From: Gcc On Behalf Of Richard Biener >> Sent: Tuesday, March 10, 2020 11:12 AM >> To: Kewen.Lin >> Cc: GCC Development ; Segher Boessenkool >> >> Subject: Re: How to extend SLP to support this case >> >>

Re: How to extend SLP to support this case

Hi Richi, on 2020/3/10 下午7:14, Richard Biener wrote: > On Tue, Mar 10, 2020 at 12:12 PM Richard Biener > wrote: >> >> On Tue, Mar 10, 2020 at 7:52 AM Kewen.Lin wrote: >>> >>> Hi all, >>> >>> I'm investigating whether GCC can vectorize the below case on ppc64le. >>> >>> extern void test(unsigne

[RFC, doloop] How to deal with invariants introduced by doloop

Hi all, This is one question origining from PR61837, which shows that doloop pass could introduce some loop invariants against its outer loop when doloop performs and prepares the iteration count for hardware count register assignment. Even with Xionghu's simplification patch https://gcc.gnu.org

Re: [RFC, doloop] How to deal with invariants introduced by doloop

on 2020/4/17 下午7:32, Richard Biener wrote: > On Fri, Apr 17, 2020 at 1:10 PM Kewen.Lin via Gcc wrote: >> >> Hi all, >> >> This is one question origining from PR61837, which shows that doloop >> pass could introduce some loop invariants against its outer loop whe

Re: [RFC, doloop] How to deal with invariants introduced by doloop

on 2020/4/21 下午5:43, Richard Biener wrote: > On Tue, Apr 21, 2020 at 10:42 AM Kewen.Lin wrote: >> >> on 2020/4/17 下午7:32, Richard Biener wrote: >>> On Fri, Apr 17, 2020 at 1:10 PM Kewen.Lin via Gcc wrote: >>>> >>>> Hi all, >>>> >&g

Question on tree LIM

Hi, I am investigating one degradation related to SPEC2017 exchange2_r, with loop vectorization on at -O2, it degraded by 6%. By some isolation, I found it isn't directly caused by vectorization itself, but exposed by vectorization, some stuffs for vectorization condition checks are hoisted out a

Re: Question on tree LIM

Hi Richard, on 2021/7/2 下午4:07, Richard Biener wrote: > On Fri, Jul 2, 2021 at 5:34 AM Kewen.Lin via Gcc wrote: >> >> Hi, >> >> I am investigating one degradation related to SPEC2017 exchange2_r, >> with loop vectorization on at -O2, it degraded by 6%. By so

Re: Question on tree LIM

on 2021/7/2 下午7:28, Richard Biener wrote: > On Fri, Jul 2, 2021 at 11:05 AM Kewen.Lin wrote: >> >> Hi Richard, >> >> on 2021/7/2 下午4:07, Richard Biener wrote: >>> On Fri, Jul 2, 2021 at 5:34 AM Kewen.Lin via Gcc wrote: >>>> >>>>

Re: Enable the vectorizer at -O2 for GCC 12

on 2021/8/30 下午10:11, Bill Schmidt wrote: > On 8/30/21 8:04 AM, Florian Weimer wrote: >> There has been a discussion, both off-list and on the gcc-help mailing >> list (“Why vectorization didn't turn on by -O2”, spread across several >> months), about enabling the auto-vectorizer at -O2, similar to

Re: Kewen Lin as PowerPC port co-maintainer

on 2022/5/5 03:20, David Edelsohn wrote: > I am pleased to announce that the GCC Steering Committee has > appointed Kewen Lin as GCC PowerPC port Co-Maintainer. > Thanks a lot! It's a great honor for me! > Please join me in congratulating Kewen on his new role. > Kewen, please up

RFC: Make builtin types only valid for some target features

Hi, I'm working to find one solution for PR106736, which requires us to make some built-in types only valid for some target features, and emit error messages for the types when the condition isn't satisfied. A straightforward idea is to guard the registry of built-in type under the corresponding

Re: RFC: Make builtin types only valid for some target features

Hi Richard, on 2022/12/5 15:31, Richard Sandiford wrote: > "Kewen.Lin" writes: >> Hi, >> >> I'm working to find one solution for PR106736, which requires us to >> make some built-in types only valid for some target features, and >> emit error messages for the types when the condition isn't satisf

Re: RFC: Make builtin types only valid for some target features

Hi Andrew, on 2022/12/5 18:10, Andrew Pinski wrote: > On Sun, Dec 4, 2022 at 11:33 PM Richard Sandiford via Gcc > wrote: >> >> "Kewen.Lin" writes: >>> Hi, >>> >>> I'm working to find one solution for PR106736, which requires us to >>> make some built-in types only valid for some target features,