https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99395
--- Comment #18 from JuzheZhong <juzhe.zhong at rivai dot ai> --- (In reply to rguent...@suse.de from comment #17) > On Wed, 31 Jan 2024, juzhe.zhong at rivai dot ai wrote: > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99395 > > > > --- Comment #16 from JuzheZhong <juzhe.zhong at rivai dot ai> --- > > (In reply to rguent...@suse.de from comment #15) > > > On Wed, 31 Jan 2024, juzhe.zhong at rivai dot ai wrote: > > > > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99395 > > > > > > > > --- Comment #14 from JuzheZhong <juzhe.zhong at rivai dot ai> --- > > > > Thanks Richard. > > > > > > > > It seems that we can't fix this issue for now. Is that right ? > > > > > > > > If I understand correctly, do you mean we should wait after SLP > > > > representations > > > > are finished and then revisit this PR? > > > > > > Yes. > > > > It seems to be a big refactor work. > > It's not too bad if people wouldn't continue to add features not > implementing SLP ... > > > I wonder I can do anything to help with SLP representations ? > > I hope to get back to this before stage1 re-opens and will post > another request for testing. It's really mostly going to be making > sure all paths have coverage which means testing all the various > architectures - I can only easily test x86. There's a branch > I worked on last year, refs/users/rguenth/heads/vect-force-slp, > which I use to hunt down cases not supporting SLP (it's a bit > overeager to trigger, and it has known holes so it's not really > a good starting point yet for folks to try other archs). Ok. It seems that you almost done with that but needs more testing in various targets. So, if I want to work on optimizing vectorization (start with TSVC), I should avoid touching the failed vectorized due to data reference/dependence analysis (e.g. this PR case, s116). and avoid adding new features into loop vectorizer, e.g. min/max reduction with index (s315). To not to make your SLP refactoring work heavier. Am I right ?