[LLVMdev] Alias analysis issue with structs on PPC

[Reid Kleckner]

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. :)

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150316/861bc32b/attachment.html>