On 6/15/2017 11:13 PM, Ehsan Amiri wrote:> > Forgot to reply to all > > Hi Eli > >> We want to read S->b for example. The size of struct S is 64 >> bits, and seems LLVM treats it as i64. >> Below is the IR corresponding to S->b, IIRC. >> >> %0 = load i64, *i64 ptr, align 4; >> %1 = %0 lshr 8; >> %2 = %1 and 255; > > This looks fine. > > > Why can't we expect InstCombine to simplify this to an 8 bit load, > assuming each of %0 and %1 has only one use ? > >We don't aggressively narrow loads and stores in IR because it tends to block other optimizations. See https://reviews.llvm.org/D30416. -Eli -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170616/da39f767/attachment.html>
I guess it tends not to block cross block optimization opportunity, or it just happen https://reviews.llvm.org/D30416 is one? Regards, chenwj 2017-06-17 1:49 GMT+08:00 Friedman, Eli via llvm-dev < llvm-dev at lists.llvm.org>:> On 6/15/2017 11:13 PM, Ehsan Amiri wrote: > > > Forgot to reply to all > > Hi Eli > > We want to read S->b for example. The size of struct S is 64 bits, and > seems LLVM treats it as i64. > Below is the IR corresponding to S->b, IIRC. > > %0 = load i64, *i64 ptr, align 4; > %1 = %0 lshr 8; > %2 = %1 and 255; > > > This looks fine. > > > Why can't we expect InstCombine to simplify this to an 8 bit load, > assuming each of %0 and %1 has only one use ? > > > We don't aggressively narrow loads and stores in IR because it tends to > block other optimizations. See https://reviews.llvm.org/D30416. > > -Eli > > -- > Employee of Qualcomm Innovation Center, Inc. > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >-- Wei-Ren Chen (陳韋任) Homepage: https://people.cs.nctu.edu.tw/~chenwj -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170617/3f1512c7/attachment.html>
On 6/16/2017 11:44 AM, 陳韋任 wrote:> I guess it tends not to block cross block optimization opportunity, or > it just happen > https://reviews.llvm.org/D30416 <https://reviews.llvm.org/D30416> is one? > > Regards, > chenwj > > 2017-06-17 1:49 GMT+08:00 Friedman, Eli via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>: > > > We don't aggressively narrow loads and stores in IR because it > tends to block other optimizations. See > https://reviews.llvm.org/D30416 <https://reviews.llvm.org/D30416>. >I guess my previous reply was a bit too terse. We don't want to narrow loads early in the optimization pipeline because it tends to hide relationships between bitfields. In particular, overlapping loads/stores are more difficult to optimize. We want EarlyCSE/GVN/DSE/etc. to see the full-width loads and stores to make them more effective. Currently, we do narrowing in DAGCombine. D30416 is a proposal to move that slightly earlier, to the late stages of the IR optimization pipeline, so we can avoid the limitations of SelectionDAG. If you read the whole discussion on that patch, it goes into more detail about this. -Eli -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170616/b641c598/attachment.html>