Demikhovsky, Elena via llvm-dev
2018-Jan-15 18:59 UTC
[llvm-dev] GEP transformation by InstCombiner
I tried to retrieve anything from DataLayout. It contains pointer size, but how can I conclude that the GEP index can't be widened? - Elena From: Hal Finkel [mailto:hfinkel at anl.gov] Sent: Monday, January 15, 2018 20:34 To: Demikhovsky, Elena <elena.demikhovsky at intel.com>; llvm-dev at lists.llvm.org; Sanjay Patel (spatel at rotateright.com) <spatel at rotateright.com>; Chandler Carruth (chandlerc at gmail.com) <chandlerc at gmail.com>; Quentin Colombet (qcolombet at apple.com) <qcolombet at apple.com>; Craig Topper (craig.topper at gmail.com) <craig.topper at gmail.com> Cc: Breger, Igor <igor.breger at intel.com> Subject: Re: GEP transformation by InstCombiner On 01/15/2018 12:21 PM, Demikhovsky, Elena wrote: Hi all, I'm working on an out-of-tree target and encountered the following problem: InstCombiner "normalizes" GEPs and extends Index operand to the Pointer width. It works fine if you can convert pointer to integer for address calculation and I assume that all registered targets do this. The target I'm working on has very restricted ISA for the pointer calculation: ptr + int, ptr - int, ptr - ptr and ptr-compare I have full arithmetic set for 32-bit integers, but the Ptr is wider. Extending index to the Ptr width requires full arithmetic support for pointers. But, actually, it does not come from C-sources (casting Ptr to int means truncation). I'd like to add TTI (TargetTransformInfo) to InstCombiner in order to configure the width of GEP indices. The current default behavior will be preserved. What do you think? Given that this affects the canonical form of the IR, based on our current practice, it should go in DataLayout (not in TTI). InstCombine should probably know how to do the right thing for the IR even if the particular target is not compiled in. -Hal Thanks. * Elena --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -- Hal Finkel Lead, Compiler Technology and Programming Languages Leadership Computing Facility Argonne National Laboratory --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180115/5cc8e7ce/attachment.html>
Hal Finkel via llvm-dev
2018-Jan-15 19:10 UTC
[llvm-dev] GEP transformation by InstCombiner
On 01/15/2018 12:59 PM, Demikhovsky, Elena wrote:> > I tried to retrieve anything from DataLayout. It contains pointer > size, but how can I conclude that the GEP index can’t be widened? >I meant that we'd add a new field giving the preferred size for indexing arithmetic. On the other hand, in your case, and in general, would it make sense to prevent widening beyond the largest legal integer type? The legal integer types are already in DataLayout. -Hal> > > - */ Elena/* > > > > *From:*Hal Finkel [mailto:hfinkel at anl.gov] > *Sent:* Monday, January 15, 2018 20:34 > *To:* Demikhovsky, Elena <elena.demikhovsky at intel.com>; > llvm-dev at lists.llvm.org; Sanjay Patel (spatel at rotateright.com) > <spatel at rotateright.com>; Chandler Carruth (chandlerc at gmail.com) > <chandlerc at gmail.com>; Quentin Colombet (qcolombet at apple.com) > <qcolombet at apple.com>; Craig Topper (craig.topper at gmail.com) > <craig.topper at gmail.com> > *Cc:* Breger, Igor <igor.breger at intel.com> > *Subject:* Re: GEP transformation by InstCombiner > > > > > > On 01/15/2018 12:21 PM, Demikhovsky, Elena wrote: > > Hi all, > > > > I’m working on an out-of-tree target and encountered the following > problem: > > > > InstCombiner “normalizes” GEPs and extends Index operand to the > Pointer width. > > It works fine if you can convert pointer to integer for address > calculation and I assume that all registered targets do this. > > > > The target I’m working on has very restricted ISA for the pointer > calculation: > > ptr + int, ptr - int, ptr - ptr and ptr-compare > > > > I have full arithmetic set for 32-bit integers, but the Ptr is > wider. Extending index to the Ptr width requires full arithmetic > support for pointers. > > But, actually, it does not come from C-sources (casting Ptr to int > means truncation). > > > > I’d like to add TTI (TargetTransformInfo) to InstCombiner in order > to configure the width of GEP indices. > > The current default behavior will be preserved. > > What do you think? > > > Given that this affects the canonical form of the IR, based on our > current practice, it should go in DataLayout (not in TTI). InstCombine > should probably know how to do the right thing for the IR even if the > particular target is not compiled in. > > -Hal > > > > > Thanks. > > > > · */Elena/* > > > > > > > > --------------------------------------------------------------------- > Intel Israel (74) Limited > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. > > > > -- > Hal Finkel > Lead, Compiler Technology and Programming Languages > Leadership Computing Facility > Argonne National Laboratory > > --------------------------------------------------------------------- > Intel Israel (74) Limited > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. >-- Hal Finkel Lead, Compiler Technology and Programming Languages Leadership Computing Facility Argonne National Laboratory -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180115/8a30b79f/attachment-0001.html>
Demikhovsky, Elena via llvm-dev
2018-Jan-15 19:32 UTC
[llvm-dev] GEP transformation by InstCombiner
> On the other hand, in your case, and in general, would it make sense to prevent widening beyond the largest legal integer type? The legal integer types are already in DataLayout.Yes, it sounds right if it does not contradict other targets behavior. I'll check. Thank you. - Elena From: Hal Finkel [mailto:hfinkel at anl.gov] Sent: Monday, January 15, 2018 21:10 To: Demikhovsky, Elena <elena.demikhovsky at intel.com>; llvm-dev at lists.llvm.org; Sanjay Patel (spatel at rotateright.com) <spatel at rotateright.com>; Chandler Carruth (chandlerc at gmail.com) <chandlerc at gmail.com>; Quentin Colombet (qcolombet at apple.com) <qcolombet at apple.com>; Craig Topper (craig.topper at gmail.com) <craig.topper at gmail.com> Cc: Breger, Igor <igor.breger at intel.com> Subject: Re: GEP transformation by InstCombiner On 01/15/2018 12:59 PM, Demikhovsky, Elena wrote: I tried to retrieve anything from DataLayout. It contains pointer size, but how can I conclude that the GEP index can't be widened? I meant that we'd add a new field giving the preferred size for indexing arithmetic. On the other hand, in your case, and in general, would it make sense to prevent widening beyond the largest legal integer type? The legal integer types are already in DataLayout. -Hal - Elena From: Hal Finkel [mailto:hfinkel at anl.gov] Sent: Monday, January 15, 2018 20:34 To: Demikhovsky, Elena <elena.demikhovsky at intel.com><mailto:elena.demikhovsky at intel.com>; llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>; Sanjay Patel (spatel at rotateright.com<mailto:spatel at rotateright.com>) <spatel at rotateright.com><mailto:spatel at rotateright.com>; Chandler Carruth (chandlerc at gmail.com<mailto:chandlerc at gmail.com>) <chandlerc at gmail.com><mailto:chandlerc at gmail.com>; Quentin Colombet (qcolombet at apple.com<mailto:qcolombet at apple.com>) <qcolombet at apple.com><mailto:qcolombet at apple.com>; Craig Topper (craig.topper at gmail.com<mailto:craig.topper at gmail.com>) <craig.topper at gmail.com><mailto:craig.topper at gmail.com> Cc: Breger, Igor <igor.breger at intel.com><mailto:igor.breger at intel.com> Subject: Re: GEP transformation by InstCombiner On 01/15/2018 12:21 PM, Demikhovsky, Elena wrote: Hi all, I'm working on an out-of-tree target and encountered the following problem: InstCombiner "normalizes" GEPs and extends Index operand to the Pointer width. It works fine if you can convert pointer to integer for address calculation and I assume that all registered targets do this. The target I'm working on has very restricted ISA for the pointer calculation: ptr + int, ptr - int, ptr - ptr and ptr-compare I have full arithmetic set for 32-bit integers, but the Ptr is wider. Extending index to the Ptr width requires full arithmetic support for pointers. But, actually, it does not come from C-sources (casting Ptr to int means truncation). I'd like to add TTI (TargetTransformInfo) to InstCombiner in order to configure the width of GEP indices. The current default behavior will be preserved. What do you think? Given that this affects the canonical form of the IR, based on our current practice, it should go in DataLayout (not in TTI). InstCombine should probably know how to do the right thing for the IR even if the particular target is not compiled in. -Hal Thanks. * Elena --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -- Hal Finkel Lead, Compiler Technology and Programming Languages Leadership Computing Facility Argonne National Laboratory --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -- Hal Finkel Lead, Compiler Technology and Programming Languages Leadership Computing Facility Argonne National Laboratory --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180115/8fac0463/attachment.html>