[PATCH] IRBuilder: Allow retrieval of the inserted instructions

Adam Nemet anemet at apple.com
Thu Feb 5 00:19:24 PST 2015


> On Feb 4, 2015, at 10:15 PM, Hal Finkel <hfinkel at anl.gov> wrote:
> 
> 
> From: "Adam Nemet" <anemet at apple.com <mailto:anemet at apple.com>>
> To: "Hal Finkel" <hfinkel at anl.gov <mailto:hfinkel at anl.gov>>
> Cc: reviews+D7421+public+86df0334cf13545b at reviews.llvm.org <mailto:reviews+D7421+public+86df0334cf13545b at reviews.llvm.org>, "llvm-commits" <llvm-commits at cs.uiuc.edu <mailto:llvm-commits at cs.uiuc.edu>>, "Nadav Rotem <nrotem at apple.com <mailto:nrotem at apple.com>> (nrotem at apple.com <mailto:nrotem at apple.com>)" <nrotem at apple.com <mailto:nrotem at apple.com>>, "Arnold Schwaighofer" <aschwaighofer at apple.com <mailto:aschwaighofer at apple.com>>, chandlerc at gmail.com <mailto:chandlerc at gmail.com>
> Sent: Wednesday, February 4, 2015 10:04:54 PM
> Subject: Re: [PATCH] IRBuilder: Allow retrieval of the inserted instructions
> 
> 
> On Feb 4, 2015, at 6:14 PM, Hal Finkel <hfinkel at anl.gov <mailto:hfinkel at anl.gov>> wrote:
> 
> 
> From: "Adam Nemet" <anemet at apple.com <mailto:anemet at apple.com>>
> To: anemet at apple.com <mailto:anemet at apple.com>, hfinkel at anl.gov <mailto:hfinkel at anl.gov>, nrotem at apple.com <mailto:nrotem at apple.com>, aschwaighofer at apple.com <mailto:aschwaighofer at apple.com>, chandlerc at gmail.com <mailto:chandlerc at gmail.com>
> Cc: llvm-commits at cs.uiuc.edu <mailto:llvm-commits at cs.uiuc.edu>
> Sent: Wednesday, February 4, 2015 5:58:45 PM
> Subject: [PATCH] IRBuilder: Allow retrieval of the inserted instructions
> 
> Hi hfinkel, nadav, aschwaighofer, chandlerc,
> 
> This is an RFC.
> 
> When the Loop Vectorizer builds the instruction sequence for checks
> it tries
> to determine the first instruction that was emitted in the current
> block.
> This is then used to split the block.
> 
> Silly question: Why don't we split the block first?
> 
> Because we may end up not needing any checks in which case we don’t split.  The decision of whether checks are necessary is local to both addRuntimeCheck and addStrideCheck.
> 
> Okay, but an alternative design would be to always split early, and then let SimplifyCFG put them back together again should we not actually end up with any checks, right? I'm not necessarily advocating for this approach, and think that the marker code will be cleaner than the existing getFirstInst code, but splitting the block eagerly will also create a trivial way of marking that point, and I want to understand if there are any downsides to that approach before we invent something new.

I am not aware of any other downsides but I haven’t written this code of course.  Hopefully Nadav/Arnold will chime in if there is something to add here.

Perhaps as another argument you could consider that there seems to be some existing practice to fix up simple things like this in the pass itself rather than relying on other passes.  Especially in this case where we could avoid producing the potential inefficiency.

I guess I am also interested if you see some gotchas with the marker feature or you just think that it’s not a generally useful new addition.

Thanks,
Adam

> Thanks again,
> Hal
> 
> Adam    
> 
> -Hal
> 
> 
> It uses a custom solution for this implemented in the static function
> getFirstInst.  The pattern is something like:
> 
> Value *V = IRBuilder.CreateBlah(...);
> FirstInst = getFirstInst(FirstInst, V, Loc)
> Value *V2 = IRBuilder.CreateBlah(...);
> FirstInst = getFirstInst(FirstInst, V2, Loc);
> 
> (Since CreateBlah may return a constant we may not generate the first
> instruction for V.)
> 
> 
> 
> 
> 
> -- 
> 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-commits/attachments/20150205/1fc1d343/attachment.html>


More information about the llvm-commits mailing list