https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64110
--- Comment #15 from Vladimir Makarov <vmakarov at gcc dot gnu.org> --- (In reply to Jakub Jelinek from comment #14) > (In reply to Vladimir Makarov from comment #13) > > (In reply to Jakub Jelinek from comment #11) > > > Looking at the generated assembly, I see there: > > > movw %di, -80(%rbp) > > > vpbroadcastw -80(%rbp), %ymm1 > > > vmovdqa %ymm1, -80(%rbp) > > > I'd have expected > > > vmovd %edi, %xmm1 > > > vpbroadcastw %xmm1, %ymm1 > > > vmovdqa %ymm1, -80(%rbp) > > > Is there some bug in the *vec_dupv16hi pattern that LRA can't use the !r > > > alternative? %di should be valid nonimmediate_operand in HImode. For > > > e.g. > > > > I know about the problem. It is coming from a different treatment of ! in > > LRA and reload. I am going to work on this but as the fix would be in very > > sensitive LRA part. I am afraid to fix it before my vacation. So probably > > it will be solved only in January. > > Np, and thanks a lot. > > The ! has been added by me for PR63594, so it isn't there from the era when > i?86 backend was using reload. If there is a better way to express that RA > should prefer to use memory or xmm register and only use r constraint if it > already is in a r register and doesn't need to be reloaded, I can use that. > Whether it is ?, ??? or something else. ! description in gcc docs just > fitted most what I wanted... Jakub, I've checked this particular test and LRA works in the same way as reload and as specified in the GCC documentation which mainly says that '!' is ignored only when *all* operands satisfy the alternative constraints. In this case there is one reload therefore alternative with '!r' is rejected. I understand that for this insn the desirable behaviour is to reject alternative only when operand with '!r' needs a reload. I could implement such functionality. The following unreserved special characters can be used as such modifier with the new functionality: @ $ ^ - What character would you prefer, Jakub?
