[LLVMdev] Alias analysis issue with structs on PPC

[Olivier Sallenave]

Daniel,

You said "more advanced AA's like CFL-AA will give up on anything that
comes from or goes through ptrtoint/inttoptr": indeed using CFL-AA doesn't
solve the noalias problem here.

But do you know why it would give up? I would understand if there was any
pointer arithmetic, but for trivial inttoptr/ptrtoint it should just
propagate the noalias information correctly.

Finally, very naive question here: why isn't CFL-AA used by default? Is
that kind of experimental so far?

Thanks,
Olivier


2015-03-16 14:24 GMT-04:00 Reid Kleckner <rnk at google.com>:

> 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/aa341431/attachment.html>