<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jul 1, 2015 at 3:07 PM, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">----- Original Message -----<br>
> From: "Bjarke Roune" <<a href="mailto:broune@google.com">broune@google.com</a>><br>
</span><div><div class="h5">> To: "Hal Finkel" <<a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a>><br>
> Cc: <a href="mailto:llvmdev@cs.uiuc.edu">llvmdev@cs.uiuc.edu</a>, "Jingyue Wu" <<a href="mailto:jingyue@google.com">jingyue@google.com</a>><br>
> Sent: Wednesday, July 1, 2015 2:27:59 PM<br>
> Subject: Re: [LLVMdev] Deriving undefined behavior from nsw/inbounds/poison for scalar evolution<br>
><br>
><br>
> On Tue, Jun 30, 2015 at 6:24 PM, Hal Finkel < <a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a> ><br>
> wrote: [...]<br>> What benefit to you get from listing i64 as a legal integer width in<br>
> the DataLayout for NVPTX?<br>
><br>
> -Hal<br>
><br>
> LSR only considers legal widths, so I think that then we could not<br>
> generate a 64 bit induction variable to get a pointer induction<br>
> variable if we make 64 bit illegal. From IVUsers.cpp:<br>
<br>
</div></div>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?<br>
<span class=""><font color="#888888"><br></font></span></blockquote>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:<br><br> 1) Strongly favors legal: LSR only considers legal induction variables.<br> 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.</div> 3) Favors legal: In SROA, we should probably prefer i64 to non-virtual-register alternatives that are harder to analyze.<br> 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.<br><div class="gmail_quote"> 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.<br> 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.<br><br></div><div class="gmail_quote">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.</div><div class="gmail_quote"><br></div><div class="gmail_quote"><div>Bjarke<br></div></div></div></div>