[LLVMdev] Deriving undefined behavior from nsw/inbounds/poison for scalar evolution (original) (raw)

Hal Finkel hfinkel at anl.gov
Wed Jul 1 15:07:14 PDT 2015

----- 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. uint64t 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 sizet 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

More information about the llvm-dev mailing list