https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119702
--- Comment #15 from Segher Boessenkool <segher at gcc dot gnu.org> --- (In reply to Avinash Jayakar from comment #14) > (In reply to Surya Kumari Jangala from comment #12) > > Ok. We also need to tackle the original issue, which is that a shift left > > can be optimized by generating a vector add. Perhaps tackle this issue > > first? > > I looked furthur into how vector multiply is lowered to shifts. This happens > in the "tree vectorization slp" pass, which transforms the gimple into > vectorized form. As well as in many other places. Importantly in expand_mult() (in expmed.cc). > If I disable this multiply pattern during vectorization, then the expand > pass converts mult to shift instruction. It should do that always, since it is cheaper always (for us). > If we want to convert mult to an add in a machine dependent pass and not > change the machine independent gimple and rtl passes, then I see that only > way would be to combine the 2 instructions (splat and shift) into one add. > @Segher/@Surya, do you have any other suggestions? Just have it recognised by a define_insn that generates an addition insn when generating assembler code. You know... the same as always :-) > (In reply to Segher Boessenkool from comment #13) > > mults. And in most cases additions are faster than shifts (or you can do > > more > > of them concurrently or similar), so in many cases they are preferred, but > > that > > is not so super obvious already. You might be able to do four adds > > concurrently, > > but you might be able to do two shifts concurrently additionally, so it all > > Here concurrency means the instruction level parallelism right for e.g., the > concurrent execution of shift/add depends on the number of functional units > in the processor right? Just wanted to be on the same page. I did not use the word "concurrency", a word that is more often abused than used correctly. I said "concurrently", which is plain English https://www.collinsdictionary.com/dictionary/english/concurrently 1. taking place at the same time or in the same location It is a very general term. Concurrency is as well really, but is often understood to mean paralellism, indeed (which is just one very particular kind of concurrency). Most things in OoO processing are concurrent things (a CPU executes one insn at the same time as fetching the next one, say), also on CPUs that cannot execute (or dispatch, or issue) multiple insns at the same time :-) But sure, ILP is a great example of the things I hinted at here :-)
