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>
Olivier Sallenave
2015-Mar-16 19:51 UTC
[LLVMdev] Alias analysis issue with structs on PPC
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>
On Mon, Mar 16, 2015 at 12:51 PM Olivier Sallenave <ol.sall at gmail.com> wrote:> 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. >It could, as long as it was directly intoptr/ptrtoint, not give up. But here you have a further problem: You are calling intoptr on an argument. In general, it has no idea where this argument came from. It has no idea what this int points to. It can't say anything reasonable about it other than "no idea". If it sees the call and the callee, interprocedural analysis could try to do something, but you are still going to have bad results in the non-LTO case (and even then, in the non-whole-program case) This will be true of *all* pointer analysis, not just CFL-AA. In any case, George, want to put "update ptrtoint/inttoptr to wait until it sees an operation happen on the the pointer before declaring it bad" on the list of stuff to do?> > Finally, very naive question here: why isn't CFL-AA used by default? Is > that kind of experimental so far? >There are some bugs remaining to be worked out, and then tuning likely needs to happen in other passes . When you give better AA answers than you had before, and increase freedom for optimizers/scheduling/regalloc to do things, the initial results tend to be negative because they become over-aggressive :)> > 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/bb2cda9a/attachment.html>
----- 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