[PATCH, PowerPC] Fix invalid displacement created by LocalStackAlloc

Hal Finkel hfinkel at anl.gov
Fri Jul 11 09:08:54 PDT 2014


----- Original Message -----
> From: "Ulrich Weigand" <Ulrich.Weigand at de.ibm.com>
> To: "llvm-commits" <llvm-commits at cs.uiuc.edu>
> Cc: "Hal Finkel" <hfinkel at anl.gov>
> Sent: Friday, July 11, 2014 8:08:57 AM
> Subject: [PATCH, PowerPC] Fix invalid displacement created by LocalStackAlloc
> 
> 
> 
> Hello,
> 
> the recent change to clang to enable dynamic stack reallocation for
> over-aligned byval parameters has triggered a pre-existing code-gen
> bug in
> LocalStackAlloc on PowerPC in one of my test cases.  (This has
> nothing to
> do with the dynamic realloc as such, the extra local copies simply
> enlarged
> the stack frame in the test case, so that stack displacements now
> start
> running out of range.)
> 
> The bug manifests in a MI instruction with out-of-range displacement
> after
> the LocalStackAlloc pass:
>         %vreg17<def> = LD 33184, %vreg31; mem:LD8[%g](align=32)
> G8RC:%vreg17 G8RC_and_G8RC_NOX0:%vreg31
> (In final assembler output the top bits are stripped off, resulting
> in a
> negative offset loading from below the stack pointer.)
> 
> This instruction was created by PPCRegisterInfo::resolveFrameIndex,
> which
> adds an offset to the FI offset already present in the instruction
> before,
> without verifying whether the resulting total offset is still in
> range.
> Now, the LocalStackAlloc common code will actually call another
> target
> routine, PPCRegisterInfo::isFrameOffsetLegal, to let the target
> decide
> whether the replacement is valid.  However, in the PowerPC
> implementation
> of that routine, we only check that whether the offset *delta* is
> itself in
> range, not whether resulting new *total* offset (FI offset already in
> the
> instruction *plus* the delta offset) is in range.
> 
> Common code however clearly expects the target to validate the total
> offset, and implementations of isFrameOffsetLegal on other targets
> agree
> with that, so it seems this is simply a bug in the PowerPC
> implementation.
> 
> Note that there is another call to isFrameOffsetLegal from *within*
> the
> PowerPC back-end (needsFrameBaseReg), where the *caller* already adds
> the
> instruction offset before calling isFrameOffsetLegal.   When changing
> isFrameOffsetLegal to perform this addition itself, that
> needsFrameBaseReg
> must then be adapted as well.
> 
> The following patch implements this, which fixes my test case (and
> passed
> regression test & bootstrap).
> 
> Is this OK to commit or am I missing something here?

Good catch! LGTM, thanks!

 -Hal

> 
> (See attached file: diff-llvm-fix-lsaoffset)
> 
> 
> Mit freundlichen Gruessen / Best Regards
> 
> Ulrich Weigand
> 
> --
>   Dr. Ulrich Weigand | Phone: +49-7031/16-3727
>   STSM, GNU/Linux compilers and toolchain
>   IBM Deutschland Research & Development GmbH
>   Vorsitzende des Aufsichtsrats: Martina Koederitz |
>   Geschäftsführung: Dirk
> Wittkopp
>   Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
> Stuttgart, HRB 243294

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory




More information about the llvm-commits mailing list