[llvm-dev] GEP transformation by InstCombiner

Hal Finkel via llvm-dev llvm-dev at lists.llvm.org
Mon Jan 15 10:33:52 PST 2018


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180115/3a823830/attachment.html>


More information about the llvm-dev mailing list