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 >

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

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: 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

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: 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: 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

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: [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

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

[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: 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 vect

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 >> >> Subjec

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

How to extend SLP to support this case

Hi all, I'm investigating whether GCC can vectorize the below case on ppc64le. extern void test(unsigned int t[4][4]); void foo(unsigned char *p1, int i1, unsigned char *p2, int i2) { unsigned int tmp[4][4]; unsigned int a0, a1, a2, a3; for (int i = 0; i < 4; i++, p1 += i1, p2

Re: Options disabled under -Os

on 2019/12/19 上午12:49, visda.vokhsho...@microchip.com wrote: > Hello, > > In GCC documentation, 3.1 Options that Control Optimization: it is indicated > -Os disables alignment of functions, jumps, labels, and loops. However, with > -v -Q passed to the compile step, I see all these options enab

Re: Commit messages and the move to git

Hi, on 2019/11/4 下午6:29, Richard Earnshaw (lists) wrote: > With the move to git fairly imminent now it would be nice if we could agree > on a more git-friendly style of commit messages; and, ideally, start using > them now so that the converted repository can benefit from this. > > Some tools,

Re: [RFC] Confusing fall through BB pc in conditional jump

Hi Segher, Thanks a lot for the comments. on 2019/6/28 上午9:32, wrote: > Hi Kewen, > > On Thu, Jun 27, 2019 at 10:32:18AM +0800, Kewen.Lin wrote: >> 6: NOTE_INSN_BASIC_BLOCK 2 >> >>12: r135:CC=cmp(r122:DI,0) >>13: pc={(r135:CC!=0)?

[RFC] Confusing fall through BB pc in conditional jump

Hi all, 6: NOTE_INSN_BASIC_BLOCK 2 12: r135:CC=cmp(r122:DI,0) 13: pc={(r135:CC!=0)?L52:pc} REG_DEAD r135:CC REG_BR_PROB 1041558836 31: L31: 17: NOTE_INSN_BASIC_BLOCK 3 The above RTL seq is from pass doloop dumping with -fdump-rtl-all-slim, I misunderstood

Re: [PowerPC 64]r12 is not updated to GEP when control transferred from virtual thunk function .

Hi Eric, Thanks for the information! Sorry to know dual entry isn't supported well on VxWorks. Thanks, Kewen on 2019/5/17 下午3:24, Eric Botcazou wrote: >> I do think so. The call is locally, linker should know it's local and >> fix it up with local entry instead. We don't need to keep r12 alwa

Re: [PowerPC 64]r12 is not updated to GEP when control transferred from virtual thunk function .

Hi, on 2019/5/16 上午7:37, Segher Boessenkool wrote: > Hi Umesh, > > Please spell out "global entry point", almost everything and everyone does. > > On Wed, May 15, 2019 at 08:57:29PM +0530, Umesh Kalappa wrote: > >> .set.LTHUNK0,_ZN12Intermediate1vEv > >> _ZThn8_N12Intermediate1vEv: