[Bug libstdc++/101583] [12 Regression] error: use of deleted function when building gold
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101583 Arjan van de Ven changed: What|Removed |Added CC||arjan at linux dot intel.com --- Comment #6 from Arjan van de Ven --- the original bug was backported to the stable 11 branch... .. should the fix be as well ?
[Bug target/101891] Adjust -fzero-call-used-regs to always use XOR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101891 Arjan van de Ven changed: What|Removed |Added CC||arjan at linux dot intel.com --- Comment #7 from Arjan van de Ven --- from a performance angle, the xor-only sequence is not so great at all; modern CPUs are really good at eliminating mov's so that's why the code originally was added to do a combo of xor and mov.. I can understand the security versus performance tradeoff. (the original tuning was done to basically make it entirely free, so that it could just be always enabled)
[Bug target/101891] Adjust -fzero-call-used-regs to always use XOR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101891 --- Comment #9 from Arjan van de Ven --- I don't have recent measurements since we did this work quite some time ago. basically on the CPU level (speaking for Intel style cpus at least), a CPU can eliminate (meaning: no execution resources used) 1 to 3 (depending on generation) register to register per clock cycle.. There's ALSO a path in the hardware for optimizing XOR sequences to avoid execution resources... when we did both we maximized the total number of these eliminations... while only XOR you can get bottlenecked on execution if you have too many. (all the mov's should have no other instructions depending on them, so even though they depend on the XOR, they're still fully 'orphan' for the out of order engine)
[Bug target/101456] Unnecessary vzeroupper when upper bits of YMM registers already zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101456 Arjan van de Ven changed: What|Removed |Added CC||arjan at linux dot intel.com --- Comment #1 from Arjan van de Ven --- Actually it's not that they're zero (they are) but they're in "init" state since the vpxor wrote to xmm not ymm
