[LLVMdev] Alias analysis issue with structs on PPC

[Hal Finkel]

----- Original Message -----
> From: "Reid Kleckner" <rnk at google.com>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "Olivier Sallenave" <ol.sall at gmail.com>, "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>
> Sent: Monday, March 16, 2015 1:24:34 PM
> Subject: Re: [LLVMdev] Alias analysis issue with structs on PPC
> 
> On Mon, Mar 16, 2015 at 9:56 AM, Hal Finkel < hfinkel at anl.gov >
> wrote:
> 
> so just using pointer types instead of i64 will help common cases,
> but will not address the general issue. Now part of this does some
> down to using array parameters as a substitute for byval/direct
> parameters. As I recall, this was done because it allowed a natural
> partial decomposition between GPRs and stack for structures that
> straddle the number of available parameter-passing GPRs. If we could
> accomplish that with regular byval parameters and regular direct
> parameters, then we'd not need any of this array coercion, and the
> system, including for the purposes of aliasing analysis, would work
> as intended. There may be some infrastructure work required in the
> backend (SelectionDAG builder, etc.) -- Uli, if you know please
> comment -- but I think moving away from the array coercions might be
> the right solution, even if that requires some infrastructure
> enhancements.
> 
> 
> 
> So, every backend interprets 'byval' differently, but it usually
> means "pass this whole thing in stack memory". It also requires
> extra copies through memory at the IR level, so I don't think we
> should be moving towards this construct.
> 
> 
> If you want to pass things in registers, it's usually best to use SSA
> values. Even though the extra 'extractvalue' instructions look
> expensive in the IR, they lower down to simple virtual register
> copies in the selection dag. The shift and trunc, on the other hand,
> don't model the machine code at all, and it would be good if we
> could eliminate them.
> 
> 
> I wonder if we could solve this parameter alignment problem via the
> 'align' parameter attribute. Unfortunately, I think for pointer
> types it's already overloaded to describe the alignment of the
> pointee and not the argument itself. In fact, I think you did this
> Hal. :)

Indeed I did :)

> 
> 
> I think, in the long term, we should probably use a direct FCA. I
> believe this is what ARM does. It's also nice to flatten the FCA if
> we can detect that we're in a simple case where no interesting
> alignment is required.

I agree, this seems to make a lot of sense (I'm assuming FCA == first class aggregate). We could make align on an FCA mean the right thing as necessary.

 -Hal

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