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 772A43857835 for ; Tue, 8 Jun 2021 06:56:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 772A43857835 Received: by mail-ed1-x532.google.com with SMTP id s6so23263275edu.10 for ; Mon, 07 Jun 2021 23:56:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BvjwO2JWTZbltpZstwqpzCNwCC/jzvRSQOi5kiy2/54=; b=ueUdrkB3PgB08TeQnKQpVFNcDG0jfJ8xcuG7nzOkxTWWMlIZMq5W6YVLHkJQiYqMDr GJR8sLyHMC0OqaLvWuDkQZfT05pljjBlRklvqpdp4guhw8TQTES/UzS212pm3DNzat2y N3Tv1lCSGgxJwgLdZJps3ppkyuTIHYJ4WqTy388mDgwTCoWukdLsi1ncsSaev1xlobg0 J01Iww34QShlF7ArXCk2Z8R6TTU5IVKzmavEhB8w1z1FDbAPasT4vCefhgwqISmL/pZY h84Vp532DRmr2A1SK40koyMbdPyhyCd8VniWuYEZR8X8TovOf8KDaOzXpaQ64pk3w4Vh KdHQ== X-Gm-Message-State: AOAM533FW3+SRAYAlmBipn+A23wHpCfnIGQhP8vcmfZx6AF0DyMKbqUe +K35KIuFVIIzhRryJmArbD6jASqXDb+2Be2q9lk= X-Google-Smtp-Source: ABdhPJxfQcA95MlF9MIF6olbuKCIBJpk+F4/2OcfPcRFu20AORNAzcDImqNHkZTuNQewhlB0lXHPwopsSPmLBa2UU9Y= X-Received: by 2002:a05:6402:51d0:: with SMTP id r16mr15158247edd.138.1623135409314; Mon, 07 Jun 2021 23:56:49 -0700 (PDT) MIME-Version: 1.0 References: <98179c8e-bcec-83ed-5b99-6f54791bd7cd@tachyum.com> In-Reply-To: <98179c8e-bcec-83ed-5b99-6f54791bd7cd@tachyum.com> From: Richard Biener Date: Tue, 8 Jun 2021 08:56:38 +0200 Message-ID: Subject: Re: Aligning stack offsets for spills To: Jeff Law Cc: GCC Patches Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-9.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2021 06:56:52 -0000 On Mon, Jun 7, 2021 at 9:00 PM Jeff Law wrote: > > > So, as many of you know I left Red Hat a while ago and joined Tachyum. > We're building a new processor and we've come across an issue where I > think we need upstream discussion. > > I can't divulge many of the details right now, but one of the quirks of > our architecture is that reg+d addressing modes for our vector > loads/stores require the displacement to be aligned. This is an > artifact of how these instructions are encoded. > > Obviously we can emit a load of the address into a register when the > displacement isn't aligned. From a correctness point that works > perfectly. Unfortunately, it's a significant performance hit on some > standard benchmarks (spec) where we have a great number of spills of > vector objects into the stack at unaligned offsets in the hot parts of > the code. > > > We've considered 3 possible approaches to solve this problem. > > 1. When the displacement isn't properly aligned, allocate more space in > assign_stack_local so that we can make the offset aligned. The downside > is this potentially burns a lot of stack space, but in practice the cost > was minimal (16 bytes in a 9k frame) From a performance standpoint this > works perfectly. > > 2. Abuse the register elimination code to create a second pointer into > the stack. Spills would start as + offset, then either get > eliminated to sp+offset' when the offset is aligned or gpr+offset'' when > the offset wasn't properly aligned. We started a bit down this path, but > with #1 working so well, we didn't get this approach to proof-of-concept. > > 3. Hack up the post-reload optimizers to fix things up as best as we > can. This may still be advantageous, but again with #1 working so well, > we didn't explore this in any significant way. We may still look at > this at some point in other contexts. > So just as extra info - you're pre-allocating the frame (including for spills) and not using push/pop? > Here's what we're playing with. Obviously we'd need a target hook to > drive this behavior. I was thinking that we'd pass in any slot offset > alignment requirements (from the target hook) to assign_stack_local and > that would bubble down to this point in try_fit_stack_local: > > diff --git a/gcc/function.c b/gcc/function.c > index d616f5f64f4..7f441b87a63 100644 > --- a/gcc/function.c > +++ b/gcc/function.c > @@ -307,6 +307,14 @@ try_fit_stack_local (poly_int64 start, poly_int64 > length, > frame_off = targetm.starting_frame_offset () % frame_alignment; > frame_phase = frame_off ? frame_alignment - frame_off : 0; > > + if (known_eq (size, 64) && alignment < 64) > + alignment = 64; > + I'm not familiar with the spill slot allocation code in GCC (I assume the above is part of it) - do we in any way "sort" the spill slots so the extra required padding is minimal? Does the above guarantee that in the end the offset will be aligned? I assume IRA/LRA can still choose to eliminate the respective frame pointer to sth else that ends up misaligning the offset again? Thus is it a real fix or a heuristic that ends up working most of the time? The actual alignment value should be dependent on the mode and target preference and thus a target hook I suppose (you mention this applies to vector loads/stores only). Don't you have the very same issue with non-stack accesses? Richard. > /* Round the frame offset to the specified alignment. */ > > if (FRAME_GROWS_DOWNWARD) > > Thoughts? > > Jeff