[llvm-dev] Cost model is missing in InstCombiner

[Mehdi Amini via llvm-dev]

I don’t believe we document anything on this aspect.

— 
Mehdi

> On Aug 23, 2016, at 1:07 AM, Shixiong Xu <shixiong at cadence.com> wrote:
> 
> Thanks for your comments. I tried using the promotion to deal with operations on v32i8. It seems work well. As you mentioned “canonicalization”, I am wondering where I can find the document on canonicalized form of IR. When I saw truncate to minimal bitwidth in innerloop vectorization, I thought it was kind of optimization rather than canonicalization.
>  
> Shixiong
>  
> From: Hal Finkel [mailto:hfinkel at anl.gov] 
> Sent: Thursday, August 18, 2016 5:10 PM
> To: Mehdi Amini
> Cc: llvm-dev at lists.llvm.org; Shixiong Xu
> Subject: Re: [llvm-dev] Cost model is missing in InstCombiner
>  
>  
> From: "Mehdi Amini via llvm-dev" <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>
> To: "Shixiong Xu" <shixiong at cadence.com <mailto:shixiong at cadence.com>>
> Cc: llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> Sent: Thursday, August 18, 2016 11:05:35 AM
> Subject: Re: [llvm-dev] Cost model is missing in InstCombiner
> 
> +David M.
>  
>  
> On Aug 17, 2016, at 3:48 AM, Shixiong Xu via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>  
> Hi,
>  
> I think canEvaluateTruncated() in InstCombiner needs use cost model to decide whether perform optimization or not.
>  
> I’ve always seen InstCombine as doing “canonicalization” of the IR and not “optimization”. So the output of InstCombine should be in a form that is the most suitable for further analyses and transformations.
> This is exactly our traditional view. Why can the backend not be fixed to generate better code for mul <32 x i8>? It looks like the widening in the IR is something natural to get from legalization (if you set up the correct promotion preferences in *ISelLowering).
> 
>  -Hal
> 
> I’m not sure how this view fits with TTI, I may not be incompatible if used within some limits I guess?
>  
> — 
> Mehdi
>  
>  
>   Without cost model from TargetTransformInfo, aggressively optimizing IR in vector types according to the number of bits demanded may lead to scalarization of vector operations. For example, if the input IR is:
>  
>   %wide.load25 = load <32 x i8>, <32 x i8>* %231, align 1
>   %232 = zext <32 x i8> %wide.load25 to <32 x i16>
>   %233 = mul nuw nsw <32 x i16> %232, %164
>   …
>   %237 = trunc <32 x i16> %233 to <32 x i8>
>   store <32 x i8> %237, <32 x i8>* %236, align 1
>  
> ICE: EvaluateInDifferentType converting expression type to avoid cast:   %9 = trunc <32 x i16> %6 to <32 x i8>
> IC: ADD:   %6 = mul <32 x i8> %wide.load25, %wide.load
> IC: Replacing   %10 = trunc <32 x i16> %7 to <32 x i8>
>     with   %6 = mul <32 x i8> %wide.load25, %wide.load
>  
> If the target doesn’t have support for mul <32 x i8>, the inst combiner will yield less profitable code.
>  
> Cheers,
>  
> Shixiong (Jason) Xu
>  
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=DQMFaQ&c=aUq983L2pue2FqKFoP6PGHMJQyoJ7kl3s3GZ-_haXqY&r=FZEW1cDCyCU3ZbRFatG9st_R0bbu9fLOaIEKyKAe7wg&m=ESfk7Z5IaUlWUQ0rjWLN1_jpMmkVJrhyBkDHZf16Vqg&s=EI-jBeC2luAByubh3z9LdCyYUtvkbZrO_SgtrJO5CJQ&e=>
>  
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
> 
> 
> 
> -- 
> 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-dev/attachments/20160823/2972b021/attachment.html>