llvm dev - Jul 2020 - Why are generic dag combines run before target dag combines?

Hi llvm-dev,

I just tried to implement a target-specific dag combine to preempt a
generic dag combine, and I was surprised to see that it didn't work because
the generic dag combines are run first. Does anyone know the rationale for
running the generic dag combines first? I would have expected the target
dag combines to run first because they have more specific information about
what combines will be useful.

Thanks,

Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200709/7c8a4891/attachment.html>

Probably because there's also constant folding and canonicalization
transforms usually at the beginning of the generic DAG combine. In general
you probably want target combines to run after that. Is it possible to do
your combine from the generic combined form? The other option is to add a
TLI hook to disable the transform. We've got a quite a lot of those.

~Craig


On Thu, Jul 9, 2020 at 7:05 PM Thomas Lively via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi llvm-dev,
>
> I just tried to implement a target-specific dag combine to preempt a
> generic dag combine, and I was surprised to see that it didn't work
because
> the generic dag combines are run first. Does anyone know the rationale for
> running the generic dag combines first? I would have expected the target
> dag combines to run first because they have more specific information about
> what combines will be useful.
>
> Thanks,
>
> Thomas
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200709/6ba3747b/attachment.html>

Thanks, that makes sense. I'm experimenting with using ISD::SPLAT_VECTOR in
the WebAssembly backend, and setting that operation to be legal causes the
dag combiner to combine vector_insert_elts on undef vectors to
splat_vectors. Generally this is useful, but I have a very specific pattern
that this breaks because it is only correct if all the other lanes are
undef. I don't really want to disable the splat_vector combine, though. I
just want it to happen later. I guess one solution would be to add a hook
to disable the combine and then duplicate it as a target combine in a later
stage.

On Thu, Jul 9, 2020 at 7:28 PM Craig Topper <craig.topper at gmail.com>
wrote:
> Probably because there's also constant folding and canonicalization
> transforms usually at the beginning of the generic DAG combine. In general
> you probably want target combines to run after that. Is it possible to do
> your combine from the generic combined form? The other option is to add a
> TLI hook to disable the transform. We've got a quite a lot of those.
>
> ~Craig
>
>
> On Thu, Jul 9, 2020 at 7:05 PM Thomas Lively via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Hi llvm-dev,
>>
>> I just tried to implement a target-specific dag combine to preempt a
>> generic dag combine, and I was surprised to see that it didn't work
because
>> the generic dag combines are run first. Does anyone know the rationale
for
>> running the generic dag combines first? I would have expected the
target
>> dag combines to run first because they have more specific information
about
>> what combines will be useful.
>>
>> Thanks,
>>
>> Thomas
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200709/74e51027/attachment.html>