On Mon, Mar 31, 2025 at 3:07 PM Mark Wielaard <m...@klomp.org> wrote: > > On Mon, 2025-03-31 at 09:12 +0000, Kyrylo Tkachov wrote: > > > > > On 31 Mar 2025, at 09:43, Richard Biener <richard.guent...@gmail.com> > > > wrote: > > > > > > On Mon, Mar 31, 2025 at 9:41 AM Richard Biener > > > <richard.guent...@gmail.com> wrote: > > > > > > > > On Mon, Mar 31, 2025 at 9:36 AM Kyrylo Tkachov <ktkac...@nvidia.com> > > > > wrote: > > > > > > > > > > Ping. > > > > > > > > Can you reference the patch please? I'll note your mails have the > > > > tendency to > > > > end up in my spam folder (which is auto-purged after some time). > > > > Probably > > > > a setup issue at nvidias side. > > > > > > Found it. Your mails fail both DKIM and DMARC so gmail thinks you are > > > phishing me. > > > > Thanks for the review. Sorry about that, I think Mark had raised a BZ issue > > somewhere tracking this, Mark do you recall something like that? > > I’m afraid I don’t know much about email workings to address this, but if > > there’s more of a writeup on the issue I can forward it to someone > > internally who can help… > > I also thought I had a specific bug about that. But all I can find is > https://sourceware.org/bugzilla/show_bug.cgi?id=31905 which just > suggests turning on From rewriting again, which I assume is not what we > really want. > > Note that you can find how the message was received in > inbox.sourceware.org I believe your message was: > https://inbox.sourceware.org/gcc-patches/da6f5115-a6c3-4c3c-8299-4660d723c...@nvidia.com/raw > Which does show it passed dmarc at least when it came in. > If we have someone with the message as received we can compare if it > still passed dmarc or if something about the message was changed that > made it fail.
I've attached what I received and what gmail flagged as dangerous phishing. Richard. > > Cheers, > > Mark
--- Begin Message ---Hi all, In this testcase GCC tries to expand a VNx4BI vector: vector(4) <signed-boolean:4> _40; _39 = (<signed-boolean:4>) _24; _40 = {_39, _39, _39, _39}; This ends up in a scalarised sequence of bitfield insert operations. This is despite the fact that AArch64 provides a vec_duplicate pattern specifically for vec_duplicate into VNx4BI. The store_constructor code is overly conservative when trying vec_duplicate as it sees a requested VNx4BImode and an element mode of QImode, which I guess is the storage mode of BImode objects. The vec_duplicate expander in aarch64-sve.md explicitly allows QImode element modes so it should be safe to use it. This patch extends that mode check to allow such expanders. The testcase is heavily auto-reduced from a real application but in itself is nonsensical, but it does demonstrate the current problematic codegen. This the testcase goes from: pfalse p15.b str p15, [sp, #6, mul vl] mov w0, 0 ldr w2, [sp, 12] bfi w2, w0, 0, 4 uxtw x2, w2 bfi w2, w0, 4, 4 uxtw x2, w2 bfi w2, w0, 8, 4 uxtw x2, w2 bfi w2, w0, 12, 4 str w2, [sp, 12] ldr p15, [sp, #6, mul vl] into: whilelo p15.s, wzr, wzr The whilelo could be optimised away into a pfalse of course, but the important part is that the bfis are gone. Bootstrapped and tested on aarch64-none-linux-gnu. Given this a regression from GCC 13 is this ok for trunk now? Thanks, Kyrill Signed-off-by: Kyrylo Tkachov <ktkac...@nvidia.com> gcc/ PR middle-end/119442 * expr.cc (store_constructor): Also allow element modes explicitly accepted by target vec_duplicate pattern. gcc/testsuite/ PR middle-end/119442 * gcc.target/aarch64/vls_sve_vec_dup_1.c: New test.
0001-PR-middle-end-119442-expr.cc-Fix-vec_duplicate-into-.patch
Description: 0001-PR-middle-end-119442-expr.cc-Fix-vec_duplicate-into-.patch
--- End Message ---
