[PATCH] Fix DAG fold that didn't check legal ops

[escha]

> On May 18, 2015, at 12:31 AM, Hal Finkel <hfinkel at anl.gov> wrote:
> 
> Hi Escha,
> 
> In the future, please post patches like this using phabricator. Although trivial, it is much easier to see the full context of the patch using the web interface (because, when uploading a patch, you upload with full context and let the web interface reduce it dynamically). Please see: http://llvm.org/docs/Phabricator.html#requesting-a-review-via-the-web-interface <http://llvm.org/docs/Phabricator.html#requesting-a-review-via-the-web-interface>

Okay; I’ll use Phab from now on.

> 
>> + (!LegalOperations || TLI.isOperationLegal(ISD::AND, VT)) &&
> 
> I'd prefer that we use TLI.isOperationLegalOrCustom here; otherwise, LGTM.


For me, this came up when I was trying to implement the following optimization: when legalizing i64 AND with a custom lowering, if the high half of the output is known to be zero (for whatever reason), convert it from (AND A, B) into (ZERO_EXTEND (AND (TRUNC A, TRUNC B))). This caused an infinite DAG loop, because the DAG combine here tried to make it back into an AND even though i64 AND was not legal.

If I use “isOperationLegalOrCustom” here, the infinite loop comes back, because it believes i64 AND is okay, so it proceeds to re-create the original pattern and call back into the same legalization code.

Is what I’m doing inherently wrong, or is LegalOrCustom not the right thing here?

—escha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150518/46c4c564/attachment.html>