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

[Hal Finkel]

----- 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:
> 
> 
> ----- Original Message -----
> > From: "Bjarke Roune" < broune at google.com >
> > To: "Jingyue Wu" < jingyue at google.com >
> > Cc: llvmdev at cs.uiuc.edu
> > Sent: Tuesday, June 30, 2015 8:16:13 PM
> > Subject: Re: [LLVMdev] Deriving undefined behavior from
> > nsw/inbounds/poison for scalar evolution
> > 
> > Hi Adam,
> > 
> > Jingyue is right. We need to keep things in 32 bits because 64 bit
> > arithmetic is more expensive and because one 64 bit register
> > consumes two 32 bit registers.
> > 
> 
> 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?

 -Hal

> 
> 
> // LSR is not APInt clean, do not touch integers bigger than 64-bits.
> // Also avoid creating IVs of non-native types. For example, we
> don't want a // 64-bit IV in 32-bit code just because the loop has
> one 64-bit cast. uint64_t Width = SE -> getTypeSizeInBits ( I ->
> getType ()); if ( Width > 64 || ! DL . isLegalInteger ( Width ))
> return false ;
> 
> 
> When I wrote "we need to keep things in 32 bits", I meant that some
> 32 bit induction variables should stay in 32 bits, but we do want 64
> bit induction variables in some common cases. The usual such case is
> for pointer induction variables, since pointers are 64 bit. Another
> case is if we get programs where the indices are already 64 bit in
> the input program - we still want to do strength reduction in that
> case. This happens naturally when using a size_t as the index.
> 
> 
> 
> It may be that we would benefit from changing some of the callers of
> isLegalInteger, like the one above, to handle illegal bit widths
> better and then at that point we'd want to make 64 bit illegal.
> 
> 
> Bjarke

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