[LLVMdev] Deriving undefined behavior from nsw/inbounds/poison for scalar evolution

[Jingyue Wu]

+Justin Holewinski <jholewinski at nvidia.com>

On Thu, Jul 2, 2015 at 4:13 AM Hal Finkel <hfinkel at anl.gov> wrote:

> ----- Original Message -----
> > From: "Bjarke Roune" <broune at google.com>
> > To: "Hal Finkel" <hfinkel at anl.gov>
> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>, "Jingyue Wu" <
> jingyue at google.com>
> > Sent: Wednesday, July 1, 2015 8:02:10 PM
> > Subject: Re: [LLVMdev] Deriving undefined behavior from
> nsw/inbounds/poison for scalar evolution
> >
> >
> >
> >
> > On Wed, Jul 1, 2015 at 3:07 PM, Hal Finkel < hfinkel at anl.gov > wrote:
> >
> >
> > ----- Original Message -----
> > > From: "Bjarke Roune" < broune at google.com >
> >
> >
> > > To: "Hal Finkel" < hfinkel at anl.gov >
> > > Cc: llvmdev at cs.uiuc.edu , "Jingyue Wu" < jingyue at google.com >
> > > Sent: Wednesday, July 1, 2015 2:27:59 PM
> > > Subject: Re: [LLVMdev] Deriving undefined behavior from
> > > nsw/inbounds/poison for scalar evolution
> > >
> > >
> > > On Tue, Jun 30, 2015 at 6:24 PM, Hal Finkel < hfinkel at anl.gov >
> > > wrote: [...]
> > > What benefit to you get from listing i64 as a legal integer width
> > > in
> > > the DataLayout for NVPTX?
> > >
> > > -Hal
> > >
> > > LSR only considers legal widths, so I think that then we could not
> > > generate a 64 bit induction variable to get a pointer induction
> > > variable if we make 64 bit illegal. From IVUsers.cpp:
> >
> > I understand, but LSR is run very late, and already considers various
> > target-specific costs (addressing modes, etc.). LSR can be fixed
> > easily if that's the only relevant issue (and maybe LSR should be
> > doing this anyway for 64-bit types on 32-bit systems?). Do you get
> > any benefit from the 'canonicalizing' transformation passes from
> > having i64 being listed as a legal integer width in DataLayout?
> >
> > I agree that LSR should be doing that anyway. I think we originally
> > made i64 legal because "illegal" sounds more serious than just "not
> > the ideal size for this hardware" and PTX does have an i64 type,
> > it's just slower and takes more register space after compilation to
> > SASS. I did a quick review of all the calls to isLegalInteger,
> > fitsInLegalInteger, getLargestLegalIntTypeSize,
> > getSmallestLegalIntType. Here's the parts that jumped out at me and
> > my hunch about whether its better for i64 to be legal or illegal in
> > that place for PTX:
> >
> > 1) Strongly favors legal: LSR only considers legal induction
> > variables.
> > 2) Favors legal: In FindLoopCounter from IndVarSimplify, I think it
> > should be ok to find an i64 loop counter if there is nothing better
> > to be found. 3) Favors legal: In SROA, we should probably prefer i64
> > to non-virtual-register alternatives that are harder to analyze.
> > 4) Favors illegal: InstCombineCasts folds casts into PHIs in some
> > limited circumstances for legal types. It's probably better not to
> > do that for i64 for PTX.
> >
> > 5) Slightly favors legal: For
> > TargetTransformInfoImplBase::getOperationCost, IntToPtr and PtrToInt
> > and truncate should probably still be free for i64, since the
> > pointer is 64 bit too.
> > 6) Slightly favors legal: In combineLoadToOperationType from
> > InstCombineLoadStoreAlloca.cpp, there's really no reason that i64
> > cannot be used, since it would be replacing another 64-bit type
> > (e.g. double) that also takes 2 registers.
> >
> >
> > On the whole, having i64 legal seems better as things stand, though
> > if some of these (especially 1) were changed to deal differently
> > with illegal types, then making i64 illegal might be marginally
> > better due to 4.
> >
>
> Ah, this is very interesting.
>
> My underlying view here is that since i64 is not really a legal type in
> the hardware, we should not mark it as a legal type. What differs here from
> the normal situation is where the legalization is done. Normally we have
> the SDAG do this, but in this case, the legalization is done by some other
> part of the software stack post-LLVM. However, since the IR level
> optimizers should not contain explicit knowledge of how legalization is
> done later, this difference should be irrelevant at the IR level.
>
> I think that the correct approach here is to "fix" the few things you've
> identified so that they work reasonably for 32-bit architectures with
> 64-bit pointers, and then remove i64 from the set of legal integer types in
> DataLayout for NVPTX. I suspect this will yield the best end result for
> everyone.
>
> Thanks again,
> Hal
>
> >
> >
> > Bjarke
> >
>
> --
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150702/97d3236a/attachment.html>