Change Details

X86's decomposeMulByConstant never permits mul decomposition to shift+add/sub if the vector multiply is legal. Unfortunately this isn't great for SSE41+ targets which have PMULLD for vXi32 multiplies, but is often quite slow. This initial patch proposes to allow decomposition if the target has the SlowPMULLD flag (i.e. Silvermont), but I'm wondering whether it might be worthwhile to always do this? PMULLD appears to always have worst perf (tp or lat) than a PSLLD+PADDD/PSUBD. I'm also wondering whether we should always decompose legal vXi64 multiplies - even latest IceLake has really poor latencies for PMULLQ.

X86's decomposeMulByConstant never permits mul decomposition to shift+add/sub if the vector multiply is legal. Unfortunately this isn't great for SSE41+ targets which have PMULLD for vXi32 multiplies, but is often quite slow. This patch proposes to allow decomposition if the target has the SlowPMULLD flag (i.e. Silvermont). We also always decompose legal vXi64 multiplies - even latest IceLake has really poor latencies for PMULLQ.

X86's decomposeMulByConstant never permits mul decomposition to shift+add/sub if the vector multiply is legal. Unfortunately this isn't great for SSE41+ targets which have PMULLD for vXi32 multiplies, but is often quite slow. This initial patch proposes to allow decomposition if the target has the SlowPMULLD flag (i.e. Silvermont), but I'm wondering whether it might be worthwhile to always do this?Silvermont). PMULLD appears to always have worst perf (tp or lat) than a PSLLD+PADDD/PSUBD. I'm also wondering whether we shouldWe also always decompose legal vXi64 multiplies - even latest IceLake has really poor latencies for PMULLQ.