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

[Bjarke Roune]

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:

  // 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
<https://cs.corp.google.com/#piper///depot/google3/third_party/grte/v4_x86/release/usr/grte/v4/include/stdint.h&l=55&ct=xref_jump_to_def&cl=GROK&gsn=uint64_t>
Width <https://cs.corp.google.com/#piper///depot/google3/third_party/llvm/llvm/lib/Analysis/IVUsers.cpp&l=136&ct=xref_usages&gs=cpp:llvm::class-IVUsers::AddUsersImpl(llvm::Instruction%2520*,%2520llvm::SmallPtrSetImpl%253Cllvm::Loop%2520*%253E%2520&)::Width at google3/third_party/llvm/llvm/lib/Analysis/IVUsers.cpp:5494%257Cdef&gsn=Width>
= SE <https://cs.corp.google.com/#piper///depot/google3/third_party/llvm/llvm/include/llvm/Analysis/IVUsers.h&l=124&ct=xref_jump_to_def&cl=GROK&gsn=SE>->getTypeSizeInBits
<https://cs.corp.google.com/#piper///depot/google3/third_party/llvm/llvm/lib/Analysis/ScalarEvolution.cpp&l=3256&ct=xref_jump_to_def&cl=GROK&gsn=getTypeSizeInBits>(I
<https://cs.corp.google.com/#piper///depot/google3/third_party/llvm/llvm/lib/Analysis/IVUsers.cpp&l=115&ct=xref_jump_to_def&cl=GROK&gsn=I>->getType
<https://cs.corp.google.com/#piper///depot/google3/third_party/llvm/llvm/include/llvm/IR/Value.h&l=222&ct=xref_jump_to_def&cl=GROK&gsn=getType>());
 if (Width <https://cs.corp.google.com/#piper///depot/google3/third_party/llvm/llvm/lib/Analysis/IVUsers.cpp&l=136&ct=xref_jump_to_def&cl=GROK&gsn=Width>
> 64 || !DL <https://cs.corp.google.com/#piper///depot/google3/third_party/llvm/llvm/lib/Analysis/IVUsers.cpp&l=117&ct=xref_jump_to_def&cl=GROK&gsn=DL>.isLegalInteger
<https://cs.corp.google.com/#piper///depot/google3/third_party/llvm/llvm/include/llvm/IR/DataLayout.h&l=239&ct=xref_jump_to_def&cl=GROK&gsn=isLegalInteger>(Width
<https://cs.corp.google.com/#piper///depot/google3/third_party/llvm/llvm/lib/Analysis/IVUsers.cpp&l=136&ct=xref_jump_to_def&cl=GROK&gsn=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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150701/4e2cb500/attachment.html>