[PATCH] [SDAG] When performing post-legalize DAG combining, run the legalizer over each node in the worklist prior to combining.

[Chandler Carruth]

On Thu, Jul 17, 2014 at 12:15 PM, Chandler Carruth <chandlerc at google.com>
wrote:

> On Thu, Jul 17, 2014 at 3:11 PM, Tom Stellard <tom at stellard.net> wrote:
>
>> On Thu, Jul 17, 2014 at 04:55:00PM +0000, Chandler Carruth wrote:
>> > Hi hfinkel, grosbach,
>> >
>> > This allows the combiner to produce new nodes which need to go back
>> > through legalization. This is particularly useful when generating
>> > operands to target specific nodes in a post-legalize DAG combine where
>> > the operands are significantly easier to express as pre-legalized
>> > operations. My immediate use case will be PSHUFB formation where we need
>> > to build a constant shuffle mask with a build_vector node.
>> >
>>
>> Since the post-legalize DAG combiner is now doing combining and
>> legalizing, do we still need to run legalize as a separate pass.
>> Can we instead just do:
>>
>> combine -> legalize types -> combine w/ legalize ops
>
>
> I'm specifically going to try this, but wanted to get at least the meat of
> the patch out there to make sure folks were still OK with the general
> direction and the necessary changes I had to make to the legalization
> engine.


Just as an update here...

I now really want to submit the patch as-is in terms of functionality.

Changing the DAG ISel process to do legalizing as a combining phase makes a
*ton* of sense to me, unfortunately absolutely nothing works if you try to
do that today. =/ There are a lot of nasty, thorny, really unpleasant
problems all interacting to make this impossible today. I'm going to try to
fix a bunch of them, but I don't really want to hold up this patch which
makes writing post-legalization DAG combines strictly more flexible and
powerful (solving a specific problem they currently have) while trying to
make this brave new world a reality.

I'll be sending an email to llvmdev with some of the challenges here and
what would be required to make this happen. It doesn't look infeasible, but
it does look like a lot of work.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140719/4cea8691/attachment.html>