Josh Klontz
2015-Mar-27 15:29 UTC
[LLVMdev] Missed constant replacement opportunity with llvm.assume?
As of ToT it seems that even the simplest cases of assumes involving equality between an instruction and a constant don't cause an instruction RAUW constant. In the attached example, %channels is assumed to be 3, leading to a missed optimization opportunity with %src_c. Am I overlooking something that would cause this optimization to be invalid? v/r, Josh -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150327/24c072be/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: convert_grayscale_u8SCXY_u8SCXY.ll Type: application/octet-stream Size: 3103 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150327/24c072be/attachment.obj>
Josh Klontz
2015-Mar-28 18:00 UTC
[LLVMdev] Missed constant replacement opportunity with llvm.assume?
Opened a bug with a minimum reproducing example: https://llvm.org/bugs/show_bug.cgi?id=23055 It seems to me the issue is that InstCombiner successfully simplifies return values when they can be proven constant, but misses the same optimization opportunity for store values. v/r, Josh On Fri, Mar 27, 2015 at 11:29 AM, Josh Klontz <josh.klontz at gmail.com> wrote:> As of ToT it seems that even the simplest cases of assumes involving > equality between an instruction and a constant don't cause an instruction > RAUW constant. > > In the attached example, %channels is assumed to be 3, leading to a missed > optimization opportunity with %src_c. > > Am I overlooking something that would cause this optimization to be > invalid? > > v/r, > Josh > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150328/574d2b51/attachment.html>