void bar (char *);

void
foo (void)
{
  char buf[384];
  bar (&buf[0]);
  bar (&buf[16]);
  bar (&buf[127]);
  bar (&buf[128]);
  bar (&buf[256]);
  bar (&buf[380]);
  bar (&buf[384]);
}

compiles with -O2 -fno-omit-frame-pointer to:
        pushq   %rbp
        movq    %rsp, %rbp
        subq    $384, %rsp
        leaq    -384(%rbp), %rdi
        call    bar
        leaq    -368(%rbp), %rdi
        call    bar
        leaq    -257(%rbp), %rdi
        call    bar
        leaq    -256(%rbp), %rdi
        call    bar
        leaq    -128(%rbp), %rdi
        call    bar
        leaq    -4(%rbp), %rdi
        call    bar
        movq    %rbp, %rdi
        call    bar
        leave
        ret
but this is unnecessarily large.  As frame pointer is here only because user asked for it, the compiler knows there is always constant difference between the stack pointer and frame pointer and perhaps in machine reorg could interchange those cases which would be smaller and not slower.
For these particular leaq/movq instructions, movq %r{sp,bp}, %rdi is 3 bytes,
leaq SIMM8(%rbp), %rdi 4 bytes, leaq SIMM8(%rsp), %rdi 5 bytes, leaq SIMM32(%rbp), %rdi 7 bytes and leaq SIMM32(%rsp), %rdi 8 bytes.
So at least from code size POV, movq %rsp, %rdi is smaller than any %rbp based leaq,
and similarly leaq SIMM8(%rbp), %rdi 2 bytes smaller than leaq SIMM32(%rbp), %rdi.
So, the mov would be a win always, and for frame sizes of more than 128 bytes %rsp up to 127 offset too.
Though, I think the aliasing code hardcodes frame pointer knowledge and ditto I think
the unwinder would be quite upset if we did such changes early.