[PATCH] Make InstCombine aware of TargetTransformInfo when optimize extension

[Justin Holewinski]

On Jul 1, 2015, at 2:44 PM, David Majnemer <david.majnemer at gmail.com<mailto:david.majnemer at gmail.com>> wrote:



On Tue, Jun 30, 2015 at 9:34 AM, Justin Holewinski <jholewinski at nvidia.com<mailto:jholewinski at nvidia.com>> wrote:

> On Jun 26, 2015, at 4:20 AM, Chandler Carruth <chandlerc at gmail.com<mailto:chandlerc at gmail.com>> wrote:
>
> This doesn't seem like the right approach at all.
>
> I don't think we want to use cost heuristics to dictate the canonical form in the IR. It makes the canonicalization *much* more complex and hard to manage.

I agree.  I would prefer not to mix the concepts of legality and performance here.

>
> I think that NVPTX should either change the datalayout to make i64 illegal (and that seems reasonable for instcombine to respect, but that would for example mean it would be an *absolute* decision, not a cost decision) or you'll need to do a late transform to narrow the operations as much as possible.

I don’t see how we could remove i64 as a legal type in NVPTX.  Our pointer size is 64-bit, so we need a container for pointers.

I think other folks are doing (or would like to be doing) this sort of thing: http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-June/087248.html

It’s a tricky situation.  64-bit pointers are legal in PTX, so defining and using them is the correct thing to do.  Performance, on the other hand, is another matter.



>
>
> http://reviews.llvm.org/D10750
>
> EMAIL PREFERENCES
>  http://reviews.llvm.org/settings/panel/emailpreferences/
>
>


-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150701/1d2d9580/attachment.html>