From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) by sourceware.org (Postfix) with ESMTPS id 9E18C385DC14 for ; Tue, 27 Sep 2022 08:39:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9E18C385DC14 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-ed1-x532.google.com with SMTP id f20so12214731edf.6 for ; Tue, 27 Sep 2022 01:39:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=gpIFilf60I7jWtmvgxB7HV5Ajb4nWqkgKV6yib6ceRg=; b=aSSt71wSg7bV9Jvn7sjX77AZLeG+mAjyTzFEmHhctZVhAf+FTPeRYkkVCL1X+227Gu ahWNnJksbmoTsAZKphB8hKKEV40ErxKOH298kI7NrS/QDfq73gJrsJ/7XNHNd8cJfXRt +Fe2EbtOA8UACEoSFpRAUY9Jc347xl7I9hGFmDrmeHfuZ6fec3wP+a36ijmCxqkIG0L2 5/MjMqmnzbcbQQRyBcAvmIaNpo8mFaoBpo5pmIeXNAF8tG4i0llW3IwDblEocrnfmCmy XsCnTJMsN1ERyRhdf6ts641D4zIbEF3c3hCcm+D9u8izJPypaMe2scdRKfMm1si12YMN CzLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=gpIFilf60I7jWtmvgxB7HV5Ajb4nWqkgKV6yib6ceRg=; b=NeTz37Sm3P22tCIwkBJaVbNxtJbDquxw4vq7X5GdUb/rEOPOeP0LxzYDI+vmKGJckt UVyT5hwjmkt7RAA5dDR0fzq+OPkSXM7W2dBwqL0ppTamNP4XXvZsF5+Ypk+rXVb6IZKt 2ly0aTUQ5zQs5ZMAawlQP4FdYXJ8nv7PxI7NgFOHBzfAm+soPilLvGBeKL0hHjsgBCfS hWJN3lyRgqKfvcEViKKuNEu+ZsOmF4KVQqdjoDGGDhBAvTBArF8d0MPtBBYzandYDZSn SyuTyxFur/ELVauNjNCvbBamU3wmDhXx+UWDPQf1y3rNGuKdabPCt/g2tfHLsci7aJJC +YOQ== X-Gm-Message-State: ACrzQf04FMqer10QqzdIz2/7YQEiLZiCv5hvWm6RivGJ447S2VVg1cSG iN5SUospSRM+meUGN0kojv2EhkzsSSsYe8J7FDM= X-Google-Smtp-Source: AMsMyM67qWN7SBpVzKW9a8izl8ywWvx+4Z72eGZtpOKPNUJlqnTOLBNV4a16PpyGphySnYXgG/Bt/8xSABscM4gr2pA= X-Received: by 2002:a05:6402:d59:b0:456:f8b7:2e40 with SMTP id ec25-20020a0564020d5900b00456f8b72e40mr15754504edb.202.1664267961159; Tue, 27 Sep 2022 01:39:21 -0700 (PDT) MIME-Version: 1.0 References: <0a9b9375-6587-5a7d-2ec9-18e7501fe179@linux.ibm.com> In-Reply-To: <0a9b9375-6587-5a7d-2ec9-18e7501fe179@linux.ibm.com> From: Richard Biener Date: Tue, 27 Sep 2022 10:39:08 +0200 Message-ID: Subject: Re: VN, len_store and endianness To: Robin Dapp Cc: GCC Patches , jakub@redhat.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Mon, Sep 26, 2022 at 4:21 PM Robin Dapp wrote: > > Hi, > > I'm locally testing a branch that enables vll/vstl for partial vector > usage i.e. len_load and len_store on s390. I see a FAIL in > testsuite/gfortran.dg/power_3.f90. > Since r13-1777-gbd9837bc3ca134 we also performe VN for masked/len stores > and things go wrong there. The problem seems to be that we evaluate a > vector constant {-1, 1, -1, 1} loaded with length 11 + 1(bias) = 12 as > {1, -1, 1} instead of {-1, 1, -1}. > > I found it a bit difficult to navigate through the logic due to several > sizes, offsets, lengths and "amounts" :) From what I can tell the > culprit code is (guarded by BYTES_BIG_ENDIAN) > > if (TREE_CODE (pd.rhs) != CONSTRUCTOR) > { > q = (this_buffer + len > - (ROUND_UP (size - amnt, BITS_PER_UNIT) > / BITS_PER_UNIT)); > } > > where, with pd.rhs = { 255, 255, 255, 255, 0, 0, 0, 1, 255, 255, 255, > 255, 0, 0, 0, 1 }, len = 16 bytes, size = 96 bits, we read after the > first 32 bits. What is supposed to happen here? It looks like going > backwards (when size grows), but actually size shrinks for my example > with each successive element via pd.offset 0, -32 and -64. > > When skipping the block with && TREE_CODE (pd.rhs) != VECTOR_CST the > test and various others succeed but I didn't pursue testing further and > figured I'd rather ask here for more insight. The error is probably in vn_reference_lookup_3 which assumes that 'len' applies to the vector elements in element order. See the part of the code where it checks for internal_store_fn_p. If 'len' is with respect to the memory and thus endianess has to be taken into account then for the IFN_LEN_STORE else if (fn == IFN_LEN_STORE) { pd.rhs_off = 0; pd.offset = offset2i; pd.size = (tree_to_uhwi (len) + -tree_to_shwi (bias)) * BITS_PER_UNIT; if (ranges_known_overlap_p (offset, maxsize, pd.offset, pd.size)) return data->push_partial_def (pd, set, set, offseti, maxsizei); likely needs to adjust rhs_off from zero for big endian? > > Regards > Robin